Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debunking Zswap and Zram Myths

chrisdown.name

Post reply on HN
Print view View original

11–20 of 70 posts

Re: Debunking Zswap and Zram Myths

#11

Post by bilegeek »

patrakov wrote: post #3

User here, who also acts as a Level 2 support for storage. The article contains some solid logic plus an assumption that I disagree with. Solid logic: you should prefer zswap if you have a device that can be used for swap . Solid logic: zram + other swap = bad due to LRU inversion (zram becomes a dead weight in memory). Advice that matches my observations: zram works best when paired with a user-space OOM killer. Bol…

Counterargument: you can mostly disable zswap writeback, so it will only use the swap partition when hibernating[1].

[1]https://wiki.archlinux.org/title/Power_management/Suspend_an...

Re: Debunking Zswap and Zram Myths

#13

Post by justsomehnguy »

patrakov wrote: post #3

User here, who also acts as a Level 2 support for storage. The article contains some solid logic plus an assumption that I disagree with. Solid logic: you should prefer zswap if you have a device that can be used for swap . Solid logic: zram + other swap = bad due to LRU inversion (zram becomes a dead weight in memory). Advice that matches my observations: zram works best when paired with a user-space OOM killer. Bol…

At this point just throw your shitty SSD in the garbage bin^W^W USB box and buy a proper one. OOMing would always cost you more.

And if you still need to use a shitty SSD then just increase your swap size dramatically, giving a breathing room for the drive and implicitly doing an overprovisioning for it.

Re: Debunking Zswap and Zram Myths

#14

Post by CoolGuySteve »

Would be nice if zswap could be configured to have no backing cache so it could completely replace zram. Having two slightly different systems is weird.

There's not really any difference between swap on disk being full and swap in ram being full, either way something needs to get OOM killed.

Simplifying the configuration would probably also make it easier to enable by default in most distros. It's kind of backwards that the most common Linux distros other than ChromeOS are behind Mac and Windows in this regard.

Re: Debunking Zswap and Zram Myths

#15

Post by prussian »

With zram, I can just use zram-generator[0] and it does everything for me and I don't even need to set anything up, other than installing the systemd generator, which on some distros, it's installed by default. Is there anything equivalent for zswap? Otherwise, I'm not surprised most people are just using zram, even if sub-optimal.

[0]: https://crates.io/crates/zram-generator

Re: Debunking Zswap and Zram Myths

#16

Post by guenthert »

cdown wrote: post #8
guenthert wrote: post #7

So much polemic and no numbers? If it is a performance issue, show me the numbers!

There are quite a few numbers in the article, although of course I'm happy to hear any more you'd like presented. * A counterintuitive 25% reduction in disk writes at Instagram after enabling zswap * Eventual ~5:1 compression ratio on Django workloads with zswap + zstd * 20-30 minute OOM stalls at Cloudflare with the OOM killer never once firing under zram The LRU inversion argument is just plain from the code presen…

> The LRU inversion argument is just plain from the code presented and a logical consequence of how swap priority and zram's block device architecture interact, I'm not sure numbers would add much there.

Yes, while it is all very plausible, the run times of a given workload (on a given, documented system) known to cause memory pressure to the point of swapping with vanilla Linux (default swappiness or some appropriate value), zram and zswap would be appreciated.

https://linuxblog.io/zswap-better-than-zram/ at least qualifies that zswap performs better when using a fast NVMe device as swap device and zram remains superior for devices with slow or no swap device.

Re: Debunking Zswap and Zram Myths

#17

Post by adgjlsfhk1 »

CoolGuySteve wrote: post #14

Would be nice if zswap could be configured to have no backing cache so it could completely replace zram. Having two slightly different systems is weird. There's not really any difference between swap on disk being full and swap in ram being full, either way something needs to get OOM killed. Simplifying the configuration would probably also make it easier to enable by default in most distros. It's kind of backwards t…

Very much agreed. I feel like distros still regularly get this wrong (as evidence, Ubuntu, PopOS and Fedora all have fairly different swap configs from each other).

Re: Debunking Zswap and Zram Myths

#18

Post by alfanick »

prussian wrote: post #15

With zram, I can just use zram-generator[0] and it does everything for me and I don't even need to set anything up, other than installing the systemd generator, which on some distros, it's installed by default. Is there anything equivalent for zswap? Otherwise, I'm not surprised most people are just using zram, even if sub-optimal. [0]: https://crates.io/crates/zram-generator

This should've been a bash script...

Re: Debunking Zswap and Zram Myths

#19

Post by cdown »

CoolGuySteve wrote: post #14

Would be nice if zswap could be configured to have no backing cache so it could completely replace zram. Having two slightly different systems is weird. There's not really any difference between swap on disk being full and swap in ram being full, either way something needs to get OOM killed. Simplifying the configuration would probably also make it easier to enable by default in most distros. It's kind of backwards t…

This is actually something we're actively working on! Nhat Pham is working on a patch series called "virtual swap space" (https://lwn.net/Articles/1059201/) which decouples zswap from its backing store entirely. The goal is to consolidate on a single implementation with proper MM integration rather than maintaining two systems with very different failure modes. It should be out in the next few months, hopefully.

Re: Debunking Zswap and Zram Myths

#20

Post by quapster »

The interesting meta-point here is how a kernel mechanism turned into cargo-cult tuning advice.

"Use zram, save your SSD" made sense in the era of tiny eMMC, no TRIM, and mystery flash controllers. It also fit a very human bias: disk I/O feels scary and finite, CPU cycles feel free and infinite. So zram became a kind of talisman you enable once and never think about again.

But the kernel isn't optimizing for your feelings about SSD wear, it's optimizing for global memory pressure. zswap fits into that feedback loop, zram mostly sits outside it. Once you see that, the behavior people complain about ("my system thrashes and then dies mysteriously") stops being mysterious: they effectively built a second, opaque memory pool that the MM subsystem can't reason about or reclaim from cleanly.

What's funny is that on modern desktops and servers, the alleged downside of zswap (writing to disk sometimes) is the one thing the hardware is extremely good at, while the downside of zram (locking cold garbage in RAM and confusing reclaim/oom) is exactly what you don't want when the machine is under stress. The folk wisdom never updated, but the hardware and the kernel did.

Post reply on HN