Re: [PATCH v6 09/13] zram: split zcomp into separate R/W streams

[Sergey Senozhatsky]

On (26/10/23 13:05), Brian Geffon wrote:
> On Tue, Oct 20, 2026 at 10:43 PM Sergey Senozhatsky
> <senozhatsky@xxxxxxxxxxxx> wrote:
> >
> > Split struct zcomp_strm into separate compression (Write zcomp_cstrm)
> > and decompression (Read zcomp_dstrm) streams, and split zcomp_ops
> > context creation/destruction into create_cctx/destroy_cctx and
> > optional create_dctx/destroy_dctx callbacks.
> >
> > This decouples Read (decompression) and Write (compression) paths so
> > they no longer contend on the same per-CPU stream mutex (Writer vs
> > Reader priority inversion).  Currently, a (low priority) Writer that
> > holds the stream mutex can be preempted by a (higher priority) Reader
> > on the same CPU, which then blocks on that mutex until the Writer gets
> > to run again and releases it, which can take a long time when there
> > are other runnable tasks on that CPU.  The good news is that Read and
> > Write contexts are completely independent - compression uses its own
> > scratch buffer that decompression never touches, and decompression
> > uses its own local buffer (for spanning zsmalloc objects) that
> > compression never touches, so the Read/Write context split doesn't
> > noticeably increase memory usage.  In addition many S/W backends have
> > stateless decompression contexts.
> >
> > A quick synthetic fio test for Writer vs Reader inversion on 24 CPUs
> > (preempt=full, zstd, 48 low priority (nice 19) writers, 24 normal
> > priority (nice 0) CPU hogs and 24 high priority (nice -19) readers):
> >
> >   Metric           Base               Patched
> >   ----------------------------------------------------------
> >   Read IOPS        207k               1,150k        (+5.6x)
> >   Read clat avg    101.50 us          7.76 us       (-13.1x)
> >   Read clat stdev  5,615.90 us        30.78 us      (-182x)
> >   Read clat p99.99 258,998 us         111.10 us     (-2331x)
> >   Read clat max    1,342,600 us       11,217 us     (-120x)
> 
> These results are awesome and thanks for exploring other options. I
> agree this sounds like a great path forward.
> 
> >
> > Suggested-by: Barry Song <baohua@xxxxxxxxxx>
> > Signed-off-by: Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx>
> 
> Acked-by: Brian Geffon <bgeffon@xxxxxxxxxx>

Thank you, sir!