Linux ZRAM Rework Splits Read and Write Compression Streams

Sergey Senozhatsky of Google's Chrome/Chromium team has posted a Linux kernel patch series that reworks ZRAM's zcomp compression layer. The central change separates per-CPU read and write streams instead of making compression and decompression share the same stream and lock.

The patch rationale targets a priority-inversion case in preemptible ZRAM: a higher-priority reader can preempt a writer that already holds the shared stream lock, then block waiting for that same lock. Because decompression and compression use independent buffers, the proposal gives reads and writes separate contexts so they no longer compete for one stream.

The final part of the series changes how secondary streams used for recompression are allocated. Recompression is serialized by the device lock, so the proposal can use one compression context for that work while retaining per-CPU decompression contexts for concurrent reads.

Senozhatsky says the resulting savings range from double-digit to triple-digit kilobytes per context and per CPU in some configurations, with backends such as zstd, deflate and lz4hc called out as examples where the reduction can be notable. On machines with many CPU cores, per-CPU savings can accumulate, but the exact total depends on the compressor and configuration.

The patch author reports noticeable improvements in synthetic testing after decoupling read and write streams. That result is useful evidence for the mechanism, but it is not a universal application-performance claim: real-world impact will depend on workload, memory pressure, compressor choice, CPU topology and how heavily ZRAM is exercised.

The work was posted for review on October 5, 2026. It is therefore proposed upstream kernel development rather than functionality users should assume is present in their current distribution kernel. The currently listed mainline kernel is Linux 7.3-rc6, so this story should not be read as a released Linux 7.3 feature.