Maybe Don't Reduce Swappiness

August 31, 2017 ยท 2 minute read

Posted in: linux performance swap

On a lot of blogs and QA sites, you’ll find the recommendation to, if you have a low-RAM Linux desktop or laptop, to reduce vm.swappiness, the tuning knob that tells the kernel how much to prioritize moving unused application memory to swap to free up memory for the cache. It’s commonly recommended to reduce it to 10, and many guides recommend reducing it to extreme values like 0 (disable swap) or 1 (swap only when the only other option would be to OOM-kill processes).

The thinking behind this is that what you want in a desktop is smooth, predictable performance, not maximum throughput, which the default is tuned for. I basically agree with this thinking, but I think the conclusion is wrong.

My laptop has 4GB of RAM (low-ish for modern applications), and I have experimented with several vm.swappiness configurations. My conclusion is that setting low values (10 or 1) does prevent any swapping for quite some time, especially with light application loads. However, when a large application is loaded (looking at you, Electron apps), the system begins to thrash and become completely unresponsive for actual minutes. This is…not acceptable.

What works better for me, is actually setting vm.swappiness quite high; the default of 60 is probably fine, but I’ve been playing with 100, and it’s fine. My thinking on this is that I want the system to swap small amounts frequently, to reduce the likelihood that it will have to go into an emergency swap storm at any point. So far, this is working very well. Opening two big electron apps at once causes stutters and seconds of unresponsiveness, rather than minutes.

This advice may not be suitable for gamers, who need soft-realtime behavior for their games, and can’t deal with the stuttering I describe above. But on the other hand, setting very low swappiness values will probably be a placebo for them, because what they really need is enough RAM to run entirely from RAM, and setting vm.swappiness to low will not guarantee that; and a higher value will not cause unnecessary swapping when everything does fit handily into RAM with enough available for filesystem buffers.

Note: All of this is anecdotal. I’ve not been motivated enough to do quantitative tests.

Note also: In both cases, I’m using zswap. This might have some effect on the results.