Re: [PATCH v3 10/11] zram: use rw_semaphore for decompression streams

[Sergey Senozhatsky]

On (26/10/15 19:24), Bo Zhang wrote:
> On Thu, 15 Oct 2026 12:19:49 +0900 Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx> wrote:
> > Or perhaps we can avoid vm_map/unmap.  A slightly different approach.
> > kmalloc on fast path + memcpy (zsmalloc objects are strictly less than
> > PAGE_SIZE bytes)
> 
> I applied the kmalloc+memcpy variant on-device and re-ran the same
> Android A/B. It removes the exclusive path entirely in our workload.
> 
>                       9+10       9+10 + kmalloc fastpath
>   read contended      ~1,959     0
>   read wait_ns total  ~12 s      0
>   read wait_ns max    72-96 ms   0
>   shared              76.7%      100%
>   exclusive           23.3%      0%
>   dpin_contended      0          0
> 
> Every decompression now takes the shared (down_read) path, including the
> cross-page objects that previously had to go exclusive. The ~1,959
> residual contentions on the exclusive path are gone, and pin contention
> stays at zero, so the full read side runs concurrently with no stream
> contention.
> 
> Read-side contention end to end:
> 
>                  baseline   9+10      9+10 + kmalloc
>   read contended 24,749     ~1,959    0
>   shared         0%         76.7%     100%

Thank you.  I'll include kmalloc patch to v4 of the series.

> This is a stateless-backend result (lzo-rle). zstd/deflate have
> create_dctx and stay exclusive, so they don't benefit from shared reads
> at all - which, as you noted, is the sad part about zstd on that list.
> 
> For those backends the serialization is unavoidable, but the actual
> root cause of the long waits is still the holder being preempted or
> migrated while holding the stream. So on top of 9+10+kmalloc I tried
> a quick-and-dirty preempt-disable for synchronous backends. Allocation
> can no longer sleep under the stream, so a two-stage zram_zs_malloc()
> does a non-sleeping attempt first and, on failure, bounces into a kmalloc()
> buffer, drops the stream and retries with a sleeping GFP_NOIO.
> 
> zstd backend, same A/B workload, on top of 9+10+kmalloc:
> 
>                        9+10+kmalloc   + preempt-disable
>   cwrite_contended     14,880         48          (-99.7%)
>   cwrite_wait_ns_total 137 s          0.32 s      (-99.8%)
>   cwrite_wait_ns_max   243 ms         43 ms       (-82%)
>   dexcl_contended      15,919         54          (-99.7%)
>   dexcl_wait_ns_total  109.6 s        0.68 s      (-99.4%)
>   dexcl_wait_ns_max    145 ms         34.6 ms     (-76%)
> 
> zstd stays 100% exclusive either way; the win comes purely from the
> holder no longer being preempted/migrated, so the hold time stays short.
> It's the same mechanism that took lzo-rle read contention from 24,749 to
> 406 earlier. So the two are complementary: shared reads remove
> reader-vs-reader queuing for stateless backends, and preempt-disable
> covers the exclusive/write serialization that stateful backends can't
> avoid.
> 
> Quick and dirty, for discussion only - Patch below.

Yeah... I need to think about it, before I can join discussions
in a meaningful way.