Linux 6.2 Lands Support For Multiple Compression Streams With ZRAM
Merged last week to Linux 6.2 as part of Andrew Morton's memory management related patches is support within ZRAM for multiple compression streams.
Back in early October I wrote about a Google engineer working on this multiple compression stream support for ZRAM. The intent is on being able to handle multiple compression streams on a per-CPU basis to allow for more effective use of this kernel module for creating compressed block devices in RAM.
With this kernel work, a secondary compression algorithm could be used with a higher compression ratio albeit slower compression/decompression speeds depending upon what is hitting ZRAM or if the primary compression algorithm wasn't able to compress the contents. This could be used for things like re-compressing idle/cold pages with a higher compression algorithm/level, compressing huge-pages with Zstd, or various other possible use-cases. User-space can control this ZRAM multiple compression stream support. Google for their work on this ZRAM improvement appears to be poised to make use of this on Chrome OS.
Managing of the secondary compression algorithms can be done via new "recomp_algorithm" and "recompress" sysfs attributes now exposed under each ZRAM device. Enabling ZRAM_MULTI_COMP allows for up to four different compression algorithms to be supported.
More details on the ZRAM multiple compression streams support via the updated documentation. The code was merged to Linux 6.2 as part of the mm-stable changes.
Back in early October I wrote about a Google engineer working on this multiple compression stream support for ZRAM. The intent is on being able to handle multiple compression streams on a per-CPU basis to allow for more effective use of this kernel module for creating compressed block devices in RAM.
With this kernel work, a secondary compression algorithm could be used with a higher compression ratio albeit slower compression/decompression speeds depending upon what is hitting ZRAM or if the primary compression algorithm wasn't able to compress the contents. This could be used for things like re-compressing idle/cold pages with a higher compression algorithm/level, compressing huge-pages with Zstd, or various other possible use-cases. User-space can control this ZRAM multiple compression stream support. Google for their work on this ZRAM improvement appears to be poised to make use of this on Chrome OS.
Managing of the secondary compression algorithms can be done via new "recomp_algorithm" and "recompress" sysfs attributes now exposed under each ZRAM device. Enabling ZRAM_MULTI_COMP allows for up to four different compression algorithms to be supported.
More details on the ZRAM multiple compression streams support via the updated documentation. The code was merged to Linux 6.2 as part of the mm-stable changes.
14 Comments