Is increasing the max_pool_percent parameter for zswap a smart idea to combine concepts of zram and zswap to increase memory and decrease disk usage?

Question

I don't know if I'm missing something, but please take this with a grain of salt.

So, zram is used to reduce I/O operations on the disk by making a swap on the memory which eliminates system freezes for users with HDDs and also 'increasing' the amount of data you can put on the memory. But the downsides is that once you run out of this swap, you will lose the speed advantage and have to swap to the HDD normally which could also swap out active pages instead of sending off LRU (least recently used) data. So it just works blindlessly by trying to compress everything thrown at it.

However, zswap tries to be smarter and does what zram does but requires more I/O activity. It caches the pages that are to be swapped and once the memory pool is full it swaps the least recently used pages. But it sends incompressible data straight to the disk swap.

Now here's the question, hear me out. Wouldn't increasing the memory pool size of zswap make it equivalent to zram by adding much more available space to the RAM by allowing the RAM pool to compress much more data and be able to accept more pages before getting exhausted WHILE ALSO keeping the smart characteristics of zswap like disk caching and swapping out LRU pages? Wouldn't this be the best of both worlds?

The only downside of this is that it'd still send off incompressible data to the disk which results in disk activity. I'm not sure about this but wouldn't decreasing swappiness to 1 get rid of this issue? Or does swappiness only affect inactive pages but not pages that zswap wasn't able to compress? If so, can anybody suggest a solution to this?

Answer 1

Swappiness affects the entire swapping mechanism, so setting it to 1 will affect how the system sends pages to swap as a whole. Zswap is sort of a layer between regular RAM and the swap device, so if zswap is enabled, then swappiness will only affect how often the system will send pages to zswap. In no way does it affect zswap's writeback. It's not even aware of it.

Setting max_pool_percent higher will indeed make room for more data to be stored in RAM, but that's no different than setting a bigger disksize in zram. It has same effect, and if set too high -- can have same nasty consequences. Set it to 100 and force your system to swap, to see what I mean.

If you want to really have best of both worlds, then what you need -- is both worlds. I have zswap in front of a writeback enabled zram swap device, plus a regular disk swap device with lower priority, just in case. Zswap has all it's perks, but 3:1 compression ratio max. When zswap triggers it's own writeback, be it LRU or incompressible data -- that data is sent to zram. If it's incompressible -- a simple script triggers huge pages writeback to zram's backing_dev, if pages were LRU evicted, then zswap decompresses them before eviction, and zram compresses them again before storing, achieving higher compression ratio than zswap (using lzo or zstd, i prefer zstd,it gives ~ 5:1 compression ratio). Same script monitors how much RAM zram has consumed, and dumps entire contents to zram's backing_dev, if the cunsumption higher than needed (i set it to 30% of zswap's max_pool_percent). This way, once the system begins swapping, zswap softens up the initial performance hit, and once it's full, instead of grinding performance to a halt with disk-based swap -- zram takes the hit. And even when the data, that is being fed to zram, can't be compressed, zram will still strip zero-filled and same-filled pages from it before sending to backing_dev, resulting in even less disk i\o. Surprisingly, zswap by itself doesn't do that -- once the pool limit is hit, it just stops accepting ANY new pages, so all the zero-filled and same-filled pages are just being written to disk, slowing down i\o, and hogging cpu. Hence the zram layer.