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

51–60 of 70 posts

Re: Debunking Zswap and Zram Myths

#51

Post by hrmtst93837 »

zozbot234 wrote: post #29
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…

> Many consumer SSDs ... under synchronous writes, will regularly produce latency spikes of 10 seconds or more 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.

[flagged]

Re: Debunking Zswap and Zram Myths

#52

Post by rhnDN1 »

From the linked comment Zswap appears to write decompressed pages to disk. I assume Chesterton's fence applies, but why not write them compressed to disk and decompress when/if they need to be loaded back?

> After the folio has been decompressed into the swap cache, the compressed version stored by zswap can be freed.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Re: Debunking Zswap and Zram Myths

#53

Post by kasabali »

rhnDN1 wrote: post #52

From the linked comment Zswap appears to write decompressed pages to disk. I assume Chesterton's fence applies, but why not write them compressed to disk and decompress when/if they need to be loaded back? > After the folio has been decompressed into the swap cache, the compressed version stored by zswap can be freed. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

THIS. This boggles my mind ever since zswap landed in the kernel.

Actually, forget zswap. Why the fuck swap's on disk format hasn't been compressed in the last 2 decades when processing power has been abundant and compressors like lzo/lz4 has been in kernel tree.

Re: Debunking Zswap and Zram Myths

#54

Post by ac29 »

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

Zswap is enabled by default in Arch. Wont do anything without a backing disk swap though

Re: Debunking Zswap and Zram Myths

#55

Post by pamcake »

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…

> The assumption is simply false, and not due to the "SSD wear" argument. 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.

Do you know to what extent this can be mitigated by overprovisioning? Like only partitioning say 50% of the drive and leaving the rest free for controller as "scratch space"?

Re: Debunking Zswap and Zram Myths

#56

Post by Numerlor »

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…

> The assumption is simply false, and not due to the "SSD wear" argument. 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. This is much worse than any HDD. If a DRAMless consumer SSD is all that you have, better use zram.

Do mind that DRAMless is much less of an issue on NVMe. NVMe can use Host Memory Buffer to use system RAM for its logic, which is still orders of magnitude faster than relying on the NAND.

DRAMless is strictly worse in every way on SATA, where you really don't want to use it if you can help it; on NVMe, the difference is more about having a bad lower-quality drive or a good higher-quality drive. Having DRAM is a good indicator of the drive being good as the manufacturer is unlikely to pair it with slow NAND and controller, but lacking it doesn't necessarily mean a drive will perform badly. When comparing drives between generations, DRAMless often ends up performing better, even in loaded scenarios, compared to an older drive with DRAM.

Re: Debunking Zswap and Zram Myths

#57

Post by patrakov »

scottlamb wrote: post #25
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…

> 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…

> Is there an experiment you'd recommend to reliably show this behavior on such a SSD?

  fio --name 4k-write --rw=write --bs=4k --size=1G --filename=fio.file --ioengine=libaio --sync=1 --time_based --runtime=60 --write_iops_log=ssd --log_avg_msec=1000 --randrepeat=0 --refill_buffers=1
Then examine ssd_iops.1.log.

Results from Apacer AS350 1TB: https://pastebin.com/F6pr5g29 - the first field is the timestamp in milliseconds, the second one is the write IOs completed since the previous line.

EDIT: I was told that the test above is invalid and that I should add --direct=1. OK, here is the new log, showing the same: https://pastebin.com/Wyw6r9TC - note that some timestamps are completely missing, indicating that the SSD performed zero IOs in that second.

You may want to repeat the experiment a few times.

Re: Debunking Zswap and Zram Myths

#58

Post by adgjlsfhk1 »

tmtvl wrote: post #37
adgjlsfhk1 wrote: post #6

can you make a follow-up here for the best way to setup swap to support full disk encryption+hybernation?

If you want hibernation then you just encrypt your swap partition like you encrypt your root partition.

that's fair. I mostly just want the OS installer to handle this for me. I have 32 gigs of ram, but compile llvm now and then, so 99% of the time I don't care about swap, but 1% of the time I really do

Re: Debunking Zswap and Zram Myths

#59

Post by AlexeyBelov »

hrmtst93837 wrote: post #51
zozbot234 wrote: post #29

Earlier quoted context omitted.

> Many consumer SSDs ... under synchronous writes, will regularly produce latency spikes of 10 seconds or more 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.

[flagged]

[flagged]

Re: Debunking Zswap and Zram Myths

#60

Post by messe »

MaxCompression wrote: post #26

One underappreciated aspect of zswap vs zram is the compression algorithm choice and its interaction with the data being compressed. 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…

LLM written comments are not permitted on this site.
Post reply on HN