undefined

points

by cogman106 hours ago |

comments

by yjftsjthsd-h5 hours ago|

[-]

> and zswap sends out compressed pages to swap.

The article says they want to avoid swap hitting disk, so that seems counterproductive.

by cogman105 hours ago|

parent|

[-]

When 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.

by mrob2 hours ago|

parent|

[-]

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.

by yjftsjthsd-h2 hours ago|

parent|

[-]

I mean, if your approach is zero swap of any kind then you wouldn't be using zram or zswap and it's a moot point, right? (Not that I disagree; I also have become fond of earlyoom)

by yjftsjthsd-h4 hours ago|

parent|

prev|

[-]

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.

by cogman104 hours ago|

parent|

[-]

Yup, you are correct about decompressing before hitting disk.

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

You can tweak priorities such that zram ends up being the preferred location for swaps.

However, since it looks like just another block device, what happens is it simply gets filled up with the first swap entries and those in turn aren't written out to the disk device.

zswap works better in that way because it'll keep hotter pages in memory and sends LRU pages to the swap device. That's really the biggest reason to use zswap over zram if you are getting into a situation where you overfill your ram.

zram works best if it's the only device with the expectation that you'll OOME when it fills up.

by yjftsjthsd-h3 hours ago|

parent|

[-]

Okay, that's why we're partially talking past each other: It didn't occur to me that someone would swap to zram and something else. Yes, if disk-backed swap is in play, then zswap is the best option.