I loved zram. Back when I first started using compressed swap, it
already supported the fantastic zstd compression
algorithm[1], giving me 3.5X-4X compression routinely, while zswap never
got beyond 2.7X.
The only problem was zram was not that good if you actually needed more swap than it offered, and the system had to start using the on-disk swap partition. Zram would not send cold pages to the disk; instead, new, presumably warm, pages would be sent if zram was full.
I used to deal with it by occasionally (i.e., when I thought of it) monitoring how much swap was being used on both the devices. I had enough RAM for my modest needs that the on-disk swap was always at 0.
So I was a zram fan. I recommended it. I set it up on all my machines, and my family’s machines. I upvoted people who recommended it in reddit discussions (and sometimes downvoted people who did the opposite, heh!)
Then this article popped up in my feed a few days ago.
Problem is, this guy is a kernel developer who manages that subsystem :-) You can’t get more authoritative than that.
But more importantly, it seemed that the low compression I was unhappy with, may have improved:
On allocator selection, prefer zsmalloc over the older z3fold or zbud allocators. zsmalloc achieves much higher compression ratios by grouping similar objects, whereas the older allocators use fixed-size objects that tend to waste space. z3fold and zbud (along with the zpool interface itself) have been removed from the upstream kernel, so on a current kernel you don’t need to set this.
I won’t know for sure, of course, so now I have to try it out on my normal workload!
[1]: https://github.com/facebook/zstd – about the only good thing to come out of facebook, to my mind (although I guess https://github.com/facebook/react is a lot more popular!)