Linux 6.2 Lands Support For Multiple Compression Streams With ZRAM

[skeevy420]

On the other hand, on beefier systems it's all even better.
On those systems, having a rather small ram-swap paired with a larger one on fast storage will hit many sweet spots:
(And while for <reasons> I myself am partial to zswap, rest assured zram is no slouch here.)
- it maintains all the aforementioned advantages;
- it leaves plenty of space for precious I/O caches;
- it makes it possible to push RAM hard, whenever necessary.

That's Nirvana... Especially on long-running systems.

That's how I use Zram. Well, for two reasons -- the 2nd is that I have a ZFS root and there's a bug with ZFS swap volumes. I'm not sure if loopback images on ZFS are affected or not, but just in case they are I keep all my swap in ram with Zram. If I wasn't worried about that I'd use Zswap with a backing loopback image or swap volume on my SSD root. My non-root drives use ZFS and NTFS (Windows root; not mounted by default) so they're not good candidates for Zswap usage.

❯ zramctl                                                
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4           3.9G   4K   69B    4K       6 [SWAP]​

Since I'm not hurting for space I use LZ4. It has the fastest IO of all the available codecs to choose from to get that whopping 69b of data in and out of Zram.

[intelfx]

I see some zram users here. If you want to push your machines even further, remember to add a backing device to zram, and writeback all unused pages there using writeback/idle interface. With this, all compressed pages not accessed for a defined time period, will be written out to disk and stop wasting precious memory. Backing device usage (number of reads/writes to hard drive) can be monitored by "cat /sys/block/zram0/bd_stat".

And yes, even with 128GB RAM my system swaps to make room for huge disk cache.

see optional feature/writeback
https://www.kernel.org/doc/html/late...kdev/zram.html

Now the million-dollar question: how does this stack up to zswap? You'd think that all those configurable writeback features (which are basically attempts to glue swapping-specific functionality even deeper into zram) should end up in zswap because that's what it was made for. But they end up in zram, proliferating the zram-as-swap abuse.

[sobrus]

Now the million-dollar question: how does this stack up to zswap? You'd think that all those configurable writeback features (which are basically attempts to glue swapping-specific functionality even deeper into zram) should end up in zswap because that's what it was made for. But they end up in zram, proliferating the zram-as-swap abuse.

As far as I remember, this does NOT work properly with zswap. That's why I disable zswap when I enable zram.

echo 0 > /sys/module/zswap/parameters/enabled

To be honest, I don't think zram works with zswap in any configuration.

Zram device usually has higher swapping priority than disk swap. So there will be no disk swapping unless zram device becomes full.
Cold data will pollute faster zram device indefinitely, and if it becomes full - os will start thrashing on lower priority disk swap instead.

Zram backing device makes sure that old unused data is moved to slower device, while zram is used for hot data only.

Zram and zswap use different memory allocators and can use different compressiom algorithms, so it won't be possible to move data between them without recompression anyway.

[intelfx]

As far as I remember, this does NOT work properly with zswap. That's why I disable zswap when I enable zram.

echo 0 > /sys/module/zswap/parameters/enabled

To be honest, I don't think zram works with zswap in any configuration.

Zram device usually has higher swapping priority than disk swap. So there will be no disk swapping unless zram device becomes full.
Cold data will pollute faster zram device indefinitely, and if it becomes full - os will start thrashing on lower priority disk swap instead.

Zram backing device makes sure that old unused data is moved to slower device, while zram is used for hot data only.

Zram and zswap use different memory allocators and can use different compressiom algorithms, so it won't be possible to move data between them without recompression anyway.

I wasn't asking how zram works with zswap — obviously, they semantically conflict with each other and if you try to use both at the same time you're signing up for lots of trouble.

Instead, I was asking how does zram stack up to zswap. I. e. given two competing solutions for a common use-case of "I want to compress my RAM", which one is preferable to use

[sobrus]

I wasn't asking how zram works with zswap — obviously, they semantically conflict with each other and if you try to use both at the same time you're signing up for lots of trouble.

Instead, I was asking how does zram stack up to zswap. I. e. given two competing solutions for a common use-case of "I want to compress my RAM", which one is preferable to use

Oh, I don't really know the answer to that question. Probably depends on the workload/use case. The most obvious difference probably is that you can use zram with very tiny backing device just for compressed cold data and bigger in-memory swap. Some differences between them can be altered with tuning (you can use zswap with zmalloc allocator like zram does, to increase compression ratio, or use zram with z3fold allocator to limit memory fragmentation over time).
I don't think any of them has any clear advantage.