zram redesign splits read/write streams, cuts latency and RAM

Linux zram is getting a redesign of its compression layer that removes long-standing priority inversion between readers and writers and cuts tens to hundreds of kilobytes of per-CPU memory, depending on the backend.

Sergey Senozhatsky’s series, now queued by Andrew Morton, splits the old unified per-CPU stream into separate compression and decompression streams. Read and write paths never shared buffers, yet they still contended on one lock. With preemptible zram, a low-priority writer holding that lock could be preempted and stall a high-priority reader for a long time. Separate streams end that coupling. Synthetic tests on a 24-CPU system showed foreground read IOPS roughly doubling and worst-case completion latency falling by hundreds of times for both lz4 and zstd workloads.

Many backends decompress without mutable state, so the series also lets those readers share a stream instead of serializing on a mutex, with a per-request bounce buffer for objects that span two pages. Stateful backends such as zstd and deflate still need exclusive contexts; for them, an idle stream can be borrowed from another CPU, and only if every stream is busy does a reader sleep. That cut exclusive-path wait time and contention sharply in measurements from Bo Zhang.

Secondary recompressors, used only under a single device lock, no longer allocate full per-CPU write streams. Backend rework further avoids wasteful power-of-two kmalloc rounding and needless dictionary setup for lz4, lz4hc, and zstd, saving on the order of hundreds of kilobytes per CPU on common configurations. Morton will carry the work in the non-mm branches of mm.git going forward, treating zram as the block device it is.