Linux's ZRAM Reworked For Greater Memory Savings, Better Performance

With today's very high memory prices, the Linux ZRAM code for compressed block devices in RAM has seen a rework to provide greater memory savings. Sergey Senozhatsky of Google's Chrome/Chromium team posted the set of ZRAM patches today with a big rework to help with memory usage optimizations. The memory savings are said to be from "double digits KB to triple digits KB" per-context/per-CPU. On a per context and per CPU core basis, these improvements have the ability to add up. Senozhatsky explained of the ZRAM rework: "The zcomp redesign and backend rework happen in the final two patches. zcomp part, basically, attempts to address the priority inversion problem, that is seen on some setups. In zcomp, we have always kept Read and Write contexts together in per-CPU streams. With preemptible zram this becomes a bit of a problem, as a higher priority Reader can preempt a Writer, which may hold a stream lock, but since the compression stream is locked by the preempted Writer, the Reader gets blocked on the very same stream lock. However, we don't have any reasons to have Read and Write contexts share and compete for the stream, because Read (decompression) and Write (compression) paths are completely independent, they never touch each other's buffers. Thus, we can split compression streams into per-CPU Read streams and per-CPU Write streams, so that Readers and Writers don't block each other anymore. Kudos to Barry Song for the idea. Decoupling Reads and Writes results in noticeable performance improvements on synthetic tests. The last patch in the series builds atop of decoupled Read and Write streams and reworks the way secondary streams are handled. Secondary compression streams are only used from recompression, which is serialized by device lock, IOW it's single-threaded. However, we still allocated secondary streams per-CPU (we needed to permit concurrent Reads of recompressed objects). Because we now have dedicated R/W streams, we can allocate a singleton compression context (for recompression) yet still have per-CPU decompression contexts. This saves a notable amount of memory with some backends and configurations (e.g. zstd, deflate, lz4hc)." The patches are now out for review on the Linux kernel mailing list. Beyond the per-context/per-CPU memory savings, splitting the Zcomp backend code for ZRAM into separate read and write streams shows the ability to deliver some massive improvements as well.