21–30 of 70 posts
https://www.theregister.com/2026/03/13/zram_vs_zswap/
I prefer zswap to zram and as I linked at the end of the piece, it's not just me:
https://linuxblog.io/zswap-better-than-zram/
Maybe I am overthinking but I am wondering if this piece about myths is in any way a response to my article?
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
echo 1 > /sys/module/zswap/parameters/enabled
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…
You can technically get this behavior today using /dev/ram0 as a swap device, but it's very awkward and almost certainly a bad idea.
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…
Is there an experiment you'd recommend to reliably show this behavior on such a SSD (or ideally to become confident a given SSD is unaffected)? Is it as simple as writing flat-out for say, 10 minutes, with O_DIRECT so you can easily measure latency of individual writes? do you need a certain level of concurrency? or a mixed read/write load? etc? repeated writes to a small region vs writes to a large region (or maybe given remapping that doesn't matter)? Is this like a one-liner with `fio`? does it depend on longer-term state such as how much of the SSD's capacity has been written and not TRIMed?
Also, what could one do in advance to know if they're about to purchase such an SSD? You mentioned one affected model. You mentioned DRAMless too, but do consumer SSD spec sheets generally say how much DRAM (if any) the devices have? maybe some known unaffected consumer models? it'd be a shame to jump to enterprise prices to avoid this if that's not necessary.
I have a few consumer SSDs around that I've never really pushed; it'd be interesting to see if they have this behavior.
LZ4 (default in both) is optimized for speed at the expense of ratio — typically 2-2.5x on memory pages. zstd can push that to 3-3.5x but at significantly higher CPU cost per page fault.
The interesting tradeoff: memory pages are fundamentally different from files. They contain lots of pointer-sized values, stack frames, and heap metadata — data patterns where simple LZ variants actually perform surprisingly well relative to more complex algorithms. Going beyond zstd (e.g., BWT-based or context mixing) would give diminishing returns on memory pages while destroying latency.
So the real question isn't just "zswap vs zram" but "how much CPU are you willing to spend per compressed page, given your workload's memory access patterns?" For latency-sensitive workloads, LZ4 with zswap writeback is hard to beat.
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
echo 1 > /sys/module/zswap/parameters/enabled It's in TFA.
Edit: To be extra clear. When I was researching this, I ended up going with zram only because:
* It is the default for Fedora.
* zramctl gives me live statistics of used and compressed size.
* The zswap doc didn't help my confusion on how backing devices work (I guess they're any swapon'd device?)
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…
Thank you for reading and your critique! What you're describing is definitely a real problem, but I'd challenge slightly and suggest the outcome is usually the inverse of what you might expect. One of the counterintuitive things here is that _having_ disk swap can actually _decrease_ disk I/O. In fact this is so important to us on some storage tiers that it is essential to how we operate. Now, that sounds like patent…
But a swap witu high latency will occasionally hang the interface, and with it hang any means to free memory manually
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…
Surely "regularly" is a significant overstatement. Most people have practically never seen this failure mode. And if it only occurs under a heavy write workload, that's not something that's supposed to happen purely as a result of swapping.
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…
> Many consumer SSDs, especially DRAMless ones (e.g., Apacer AS350 1TB, but also seen on Crucial SSDs), under synchronous writes, will regularly produce latency spikes of 10 seconds or more, due to the way they need to manage their cells. Is there an experiment you'd recommend to reliably show this behavior on such a SSD (or ideally to become confident a given SSD is unaffected)? Is it as simple as writing flat-out f…
Typically QLC is significantly worse at this than TLC, since the "real" write speed is very low. In my experience any QLC is very susceptible to long pauses in write heavy scenarios.
It does depend on controller though. As an example, check out the sustained write benchmark graph here[1], you can see that a number of models starts this oscillating pattern after exhausting the pseudo-SLC buffer, indicating the controller is taking a time-out to rearrange things in the background. Others do it too but more irregularly.
> You mentioned DRAMless too, but do consumer SSD spec sheets generally say how much DRAM (if any) the devices have?
I rely on TechPowerUp, as an example compare the Samsung 970 Evo[2] to 990 Evo[3] under DRAM cache section.
[1]: https://www.tomshardware.com/pc-components/ssds/samsung-990-... (second image in IOMeter graph)
[2]: https://www.techpowerup.com/ssd-specs/samsung-970-evo-1-tb.d...
[3]: https://www.techpowerup.com/ssd-specs/samsung-990-evo-plus-1...