alt Hacker NewsWhen you do zram, what happens is the pages sent to zram are compressed. But when those compressed pages need to be evicted to swap, they are decompressed before being sent there. It's not helping you to avoid hitting the disk, it's writing more to the disk.
Zswap will still compress pages in ram. It only evicts to the disk when the in memory swap pool is filled. The difference being that the pages swapped to disk remain compressed on their way there.
Replies
I never want to evict pages to swap. If I loaded something, it's because I intend to run it, and I never want to wait. If there's not enough RAM, I'd rather have a userspace OOM killer kill the process early so I know I'm trying something impossible. (Or rely on the kernel OOM killing if it's actually capable of doing its job, but last I tried the default behavior under heavy memory pressure was to free any pages that can be restored from disk, even if swap is disabled, which makes the system equally unusable.) I don't care if rarely used pages are "wasted" by being kept in RAM. I want good worst-case performance, not good average-case performance.
I think you have it backwards.
When using zram, there is no "evicted to swap"; zram is the swap. Even if you activated zram and disk-backed swap, I'm pretty sure they just get used in parallel, not through some sort of fallback.
It was my understanding that zswap does decompress pages before writing them to disk. Annoyingly, this doesn't seem to be spelled out either way in https://www.kernel.org/doc/html/latest/admin-guide/mm/zswap.... ; https://wiki.archlinux.org/title/Zswap does say "Once the pool is full or the RAM is exhausted, the least recently used (LRU) page is decompressed and written to disk, as if it had not been intercepted." but doesn't cite that claim.
EDIT: I think my belief is backed by https://elixir.bootlin.com/linux/v7.1.2/source/mm/zswap.c#L9... -
> We are basically resuming the same swap writeback path that was intercepted with the zswap_store() in the first place. After the folio has been decompressed into the swap cache, the compressed version stored by zswap can be freed.