Not true if you enable zswap. The pages stay compressed in a RAM pool, and are only sent to the real swap on disk in their compressed states when that gets full. This significantly reduces I/O overall.
EarlyOOM, swap, and zswap is the answer combo you're looking for. With those in place and properly tuned, you'd have to have something go extraordinarily sideways for an actual issue to appear.
Why not a single swap space with zswap? I find it much easier to configure, and the performance difference can largely be eliminated with a little tuning.
I had zram set up by itself in the past, but on my most recent install I got paranoid and I decided to set up a swap partition just in case (though I dunno what happens when zram runs out of space). I suppose I may as well try zswap.
On an unrelated note: if you're the DrMcCoy from Twenty Sided and GOL it's nice to see you.
A small swap space with zswap is where it's at. You get all the benefits of swap, plus reduced I/O and high-enough speed fetches that it just feels like extra memory. Well worth configuring, IMO.
I typically enable zram instead, on modern systems disk-based swap is going to be extraordinarily sluggish, and unlikely to be the make-or-break of recovering a system if you 64GB+ of RAM was already chewed through.
zram != zswap, which is unfortunately confusing. Unlike zram, which is a fixed-size in-memory block device that can be used for swap, zswap makes its own pool for compressed pages that you can resize at will, and sends compressed pages to your real on-disk swap. This significantly reduces I/O and gives you the best of both worlds between in-memory and on-disk swap. I'll be happy to share my config if you like.
reply