Google Engineer Experimenting With ZRAM Handling For Multiple Compression Streams

There are patches that provide support for ZRAM to be able to handle multiple compression streams on a per-CPU basis. This kernel module for creating compressed block devices could be made more versatile with this proposed patch series.

Sergey Senozhatsky of Google has sent out a set of patches for supporting multiple compression streams with ZRAM. By being able to handle different compression streams, it could open up ZRAM to be more effectively utilized and leveraging the best traits of a given compression algorithm. From Google's perspective, this ZRAM work may prove useful for at least Chrome OS usage.

Sergey explained of this work:

The main idea is that different compression algorithms have different characteristics and zram may benefit when it uses a combination of algorithms: a default algorithm that is faster but have lower compression rate and a secondary algorithm that can use higher compression rate at a price of slower compression/decompression.

There are several use-case for this functionality:

- huge pages re-compression: zstd or defalte can successfully compress huge pages (~50% of huge pages on my synthetic ChromeOS tests), IOW pages that lzo was not able to compress.

- idle pages re-compression: idle/cold pages sit in the memory and we may reduce zsmalloc memory usage if we recompress those idle pages.

User-space has a number of ways to control the behavior and impact of zram recompression: what type of pages should be recompressed, size watermarks, etc. Please refer to documentation patch.

More details for those interested via this patch series.