☃️karolherbst☃️Honest question: why are we still defaulting to swap partitions in Linux distributions?
arcanicanisI love swap completely slowing down the process of reaching the threshold to trigger the OOM killer to be invoked (if at all, and hopefully not stuck in the limbo in-between), thrashing my NVMe or SSD with useless activity for several minutes into hours, to sit and watch a system be so dogged down, that you can't even log into a virtual tty without it timing out (all while the kernel is actually responsive to immediately respond to magic SysRq keycombos). It's great.
Let the kernel kill a process in an OOM situation and continue to run just fine? Use a userspace OOM killer earlier before the kernel has to step in?
As is the situation of hitting OOM whether you have swap or not. Swap just slows down the time of getting to the threshold of the OOM killer being invoked. If you're pushing into the situation where you "need" swap, it's usually going to saturate swap too, unless you have like a +8 GB or so swap volume or something, whereas as far as I'm aware, most people only have a 1GB swap by default.
@arcanicanis @boilingsteam I have 64GiB compressed RAM swap, because I also need it. And I was experimenting with chunked swap, but I don't need that much memory. ~128 GiB effective Ram is plenty.
Most of your issues come just from misconfigured swap.
The situation was worse years ago, but these days none of those issues should happen if it's set up properly.
I'm speaking from my out-of-box experience on Kubuntu 25.10, 32GB physical, +4.3(?)GB swap. I'd be totally fine with my userspace stuff being forcibly killed on OOM rather than having an unresponsive system that's hiked up with activity on shuffling things in and out of swap under pressure, with SysRq reset being the only option out.
@arcanicanis @boilingsteam forcibly killed on OOM means data loses for many, which is just not acceptable as a generic policy.
Might be fine for you, but you can't make that decision for millions of users.