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?


2 Answers 2


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.


Yes you are correct. Two factors why zram is used at all:

  1. It's commonly used on phones, where they don't have swap at all. First, because swapping would wear out the flash; second, because a lot of these use eMMC or whatever which tops out at about 100MB/sec writes and can be slower than a hard drive if doing random writes.

  2. zswap USED to have a big issue where it would only use the "zbud" or "z3fold" zpools (to actually store compressed pages). zbud only stores at 2:1 and z3fold 3:1. And zsmalloc allows for just packing compressed pages in much more efficiently, but it was unable to reuse the space! I tried it, saw something like 1.5:1 compression, it made performance worse basically.. compression ratio was too low so I'd just see higher swap usage, negating the help of the zswap.

This has changed! Within the last year or 2, patches were finally put in so zsmalloc now works fine with zswap. I've typically seen 3:1 to 5:1 compression, and once or twice it was a bit over 12:1! I switched compression algorithm to zstd as well. This does not seem at all CPU intensive, I tested on a Core 2 Duo notebook with 2GB RAM (and 16GB swap.. just in case, to the rather slow HDD). I expected even if I got a nice overall speedup, at least it'd show some CPU time shooting up on kswapd0 or some compression thread or something.. nope! It ridiculously improved the performance on it, ridiculously improved the performance on my desktop with 32GB. I turned off the tweaks to swappiness etc. to try to keep it dribbling some stuff out to swap, since that now sits in zswap and is ridiculously fast. Even if I run stuff that does need over 32GB RAM, it makes the swap behave much better as one would hope for a compressed swap cache.

(No, I'm not trying to use that Core 2 as a daily driver or something, it has a really nice screen and keyboard and it turns out a 1.5ghz Core 2 is just fast enough for nice Steam Remote Play.)

For our consideration, my zswap settings (I stuck this in /etc/rc.local but put it where you will...):

echo zstd > /sys/module/zswap/parameters/compressor
echo zsmalloc > /sys/module/zswap/parameters/zpool
#This makes it so something that is swapped back in is immediately removed from the zswap.
#Disadvantage is it needs to be recompressed if it's swapped back out again.
echo Y > /sys/module/zswap/parameters/exclusive_loads
echo Y > /sys/module/zswap/parameters/enabled

#Race condition? I think if swap is already on the zswap settings don't "kick in".
swapoff -a ; swapon -a

(The race condition I refer to, I suspect systemd is running things in parallel with rc.local, I would usually have zswap running on bootup but sometimes not.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .