Zram/zswap woes

Hello there.

I’m getting back to desktop Linux, and I’m kind of left scratching my head at the whole zram/zswap thing. Imagine my surprise when, during linking a rather large program on my laptop with 16GB of RAM (something that I’ve done on similarly-specced virtual machines with ease), kswapd and friends came to dominate the scheduler and ultimately cause the machine to wedge. (I haven’t attached kgdb from another machine yet, but I imagine I’d see every thread on my CPU preoccupied with swap-related tasks. It’d help explain why my load average steadily climbs while watching top: under that kind of pressure, nothing else can make progress.)

I can tickle this pretty consistently: I routinely do things that actually make full use of my main memory, and Project Bluefin’s (Fedora more broadly?) usurping half of that for a swap RAM disk is kind of a pain. It’d make sense if I could directly address the compressed deanonymized pages stored in zram, but I can’t, and the constant swap thrash is just killer.

The upshot is that I was very pleased to learn that I wasn’t swap thrashing my SSD, so there’s at least that.

What can I do to tune this or otherwise permanently disable swap? The compressed pages just, like, aren’t that important to me, as cool as the idea is.

To change the size, copy the file /usr/lib/systemd/zram-generator.conf to /etc/systemd/zram-generator.conf and then modify it:

sudo cp -av /usr/lib/systemd/zram-generator.conf /etc/systemd/zram-generator.conf
sudo nano /etc/systemd/zram-generator.conf

If you want to disable zram, make the file /etc/systemd/zram-generator.conf empty.

1 Like

Rad! This is exactly what I was looking for. Thanks.

For anyone following me who needs something a little more step-by-step (I’m familiar with systemd, but you might not be, say) when a reboot is undesirable, this is what I wound up doing:

sudo sh -c '> /etc/systemd/zram-generator.conf'
sudo systemctl daemon-reload
sudo systemctl stop /dev/zram0

My machine froze for a bit after telling /dev/zram0 to stop, but it pretty quickly recovered. A look at /proc/swaps afterward confirmed that there was in fact no more swap. I did get a few notes in the systemd journal about the OOM killer running, but that was expected.

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.