I am a happy ZRAM user for several years now. Basically it makes my 4GB netbook totally usable running Gnome and a Browser with a lot of open tabs.
After reading Debunking zswap and zram myths last week, I thought to give ZSWAP a trial, since the machine had a 3 GB swap partition anyway.
I disabled ZRAM, and enabled ZSWAP and configured it to use the defaults with ZSTD.
I would have expected, that my machine would perform as good as with ZRAM, perhaps a little bit slower because of accessing SWAP instead of just using the RAM.
Surprisingly, my machine froze using ZSWAP after opening at most half the amount of tabs in my browser that I would open when using ZRAM. Was the first freeze on this machine I can remember, after I made the switch to ZRAM.
I increased the zswap.max_pool_percent from its default of 20 percent to 50 percent, which improved the situation a little bit, but still the machine froze again.
I saw the the physical swap was being utilized.
I reverted back to ZRAM, where I configure by default the size to be double the amount of RAM, something like 8 GB (!), again with ZSTD. I could open an insane amount of tabs again, I saw that nothing was swapped to the physical swap, everything was in the RAM disk. No trouble, no freezing.
My question is, why do I observe this? Should not ZSWAP with 50 percent of RAM and a physical SWAP partition outperform ZRAM, at least concerning the number of open tabs in the browser? (I could understand a performance loss because of swapping to the SSD.) Why does the out of memory systemd service not trigger properly with ZSWAP?
Using Debian 13 on an Intel Celeron, in case that should be relevant.
Update:
- I understand, that ZRAM is just a compressed RAM disk and that the 8GB I configure is the size of the compressed data on it, not the actual size it takes in memory
- I understand, that ZSWAP is a caching layer in front of regular swap, integrated into the memory manager subsystem of Linux
According to my understanding, this still does not explain, why ZRAM outperforms ZSWAP. The physical RAM consumption of ZRAM with a lot of open tabs is roughly 2GB. ZSWAP should have had roughly 1.9 GB of RAM for compressed pages ) + 2.9 GB of physical swap. If we assume a compression factor of 3 this sould be roughly 1 GB of additional swap compared to ZRAM, which still performs worse. Again, in both cases ZSTD was used.
Update 2: When I write ‘freeze’, I mean full out of memory crash when using ZSWAP. The machine ‘freezes’ fully, inclusive mouse cursor and nothing happens, even if I leave it alone a few minutes. Sorry, English is my 2nd language.
I have the same experience. I don’t really understand why tbh. I have looked at some of the kernel code but I wasn’t able to understand it.
My experience is that zram has vastly more aggressive compression and can compress way more data. Zram will happily sit there and compress 7 gb of data into 1.5 gb, whereas zswap never hits those numbers.
So I disagree with the common takes about swap being needed with zram. Because zram will compress everything that would otherwise be put into swap, into the same amount of space zswap will use to store a fourth of that data, whereas everything else would be put into swap. And because decompressing is faster than swapping, it leads to a smoother experience.
Thanks a lot for sharing. I am happy, it is not just me.
Fedora uses ZRAM w/o swap by default since a few years AFAIK. ZRAM is to the best of my knowledge also heavily used in Android phones w/o swap and of course Chromebooks w/o swap.
For me, swap is never used when ZRAM is activated, I will probably not setup a partition for new installations of Debian.
I still do not get, why it seems that people like Chris Down are so strong in their recommendation for ZSWAP. Chris seems to work at META and probably sees primary server workloads. But I would expect a developer of his caliber to be able to understand and formulate, where ZRAM beats ZSWAP and the other way around. Even in his article above, he is a little bit more nuanced concerning his recommendations. My personal takeaway for now is, to use ZRAM on desktops unless I really need/want hibernation.
I think the problem is they analyze it by how it appears to work rather than measuring raw numbers. Because honestly, I don’t really understand why zram compresses better either.
Because the interactive diagram on that blogpost below “LRU inversion” is interesting, and it’s a great example of what should happen, but it’s not accurate to my experience. What actually happens, IME, is that 1, 2, 3, 4, 5, 6, , 8, 9, 10, 11, 12 stay in zram forever and never get swapped to disk. Even when I had 8 gb of ram (on the mac mini) I had that experience.
Excellent point! The whole point about ‘LRU inversion’ falls apart, if the data never leaves ZRAM in the first place.