@AdrianVovk Yup, the concept behind zswap seems to be much more fitting for us.

Still, in my experiments, zswap causes my firefox to be killed way earlier than when using the giant zram (it should be much later instead, as now there's also real disk storage available to write to).

@AdrianVovk My wild guess as to why that's happening is that the kernel isn't smart enough. I'm testing with a 16 GB swapfile in addition to my 16 GB of RAM.

The kernel now fills up the 16 GB of uncompressed RAM, then starts swapping out, keeping track of each byte that it's swapping out. As soon as it swapped out 16 GB (even though zswap didn't write anything back to disk, I checked that), memory pressure rises and the OOM killer kills firefox, when actually there's more memory available.

@verdre Have you played with:

- tuning zswap's pool size (it has a limit in terms of maximum memory use!)
- tuning zswap's compressor
- turning on the zswap shrinker, which periodically evicts cold pages to disk
- tuning vm.swapiness and the other related sysctls

Also, you're talking about memory pressure, which is managed by userspace memory killers. Are you sure it's the kernel killing your stuff and not oomd misconfigured to fire too early?

@AdrianVovk Oh yeah it's the kernel OOM killer.

I'm playing around with zswaps tunables right now actually.

I think my hypothesis is confirming though. I'm doing an absolutely cursed experiment right now and using a sparse swap file that's exposed to the kernel via a loopback device, so that I can overcommit available disk space and measure the actual data written to disk. It's now managing to load all my firefox tabs without OOMing, with almost nothing written to disk.

@AdrianVovk Okay!

Achieved the same behavior with zswap as before with zram now: 0 bytes written back to disk, while all my firefox tabs are loaded.

To get there, adjusted zswap config to disable the shrinker (so it doesn't lazy-write back to disk).