I've never had that problem. Maybe you don't setup much swap space as I would expect the system to run well enough to save your work and shutdown for most common leaks.
Swap usually makes it worse, without swap there is some chance that the Linux OOM killer does something useful and saves the system. With swap, it becomes a frozen system that never manages to kill anything due to all the swapping. You can wait 5 minutes, 10 minutes, or 15 minutes, but the system never recovers without a reboot.
That only works if the system is accessing mostly anonymous pages. If the load on the system is accessing plenty of mmapped code/data pages, it can still trash those even if swap is disabled. I've still seen systems hanging for 10+ minutes without recovering even though swap was already disabled.
The Linux kernel OOM killer only acts if there's nothing left that can be discarded, which often happens way too late to save the system. You need a user-mode OOM-killer like earlyoom if you want to keep the system responsive.
Not a long time. With swap enabled, when a process consumes too much memory your system goes from perfect performance to cursor lagging to everything is frozen and you can't even switch to a TTY within 5-10 seconds.
Without swap, the system lags for a couple seconds, OOM killer frees up memory and you're good to go again. The only slowdown is any pages that were kicked out from the file cache. But those quickly come back after the OOM killer does its thing.
What if the thing you kill is in the critical stack to saving your work? If it isn't I don't really understand why you would be swapping it in a lot
I would view the OOm solution as a compute as cattle thinb, but here we are talking about a user desktop where the user can take the best action for themselves once they realize there's a problem.
This sounds nothing like the gradual leak problem described.. An OOM killer is great once you actually run out of resources, removing virtual resources to always run out and play roulette is using it as a fad hammer.
You have only about 10sec between the system getting slower and the system locking up completely. If you manage to hit the Magic SysRq key combination to trigger OOM manually, that can save the system, but you have to be quick.
My previous Linux laptop with 8GB of RAM (2014–2017 or so, I think) I never even got round to setting up swap, and I only ran into problems two or three times total (when running two or three Firefox instances and Chromium and a VM taking 2GB and a bunch of other things running—some of the biggest consumers, namely browsers, actually notice if they’re using too much of your RAM and adjust how they work so they don’t ask for so much RAM, at what I believe is a fairly slight performance cost).
On my current laptop and with my current habits, I’m consuming a lot more memory, and so the technique I use to avoid OOM is simply having 40GB of RAM. (As it happens, I do actually have swap set up at present, because certain circumstances meant I wanted to hibernate it occasionally; should disable swap again now I’m back to not needing to hibernate.)
> some of the biggest consumers, namely browsers, actually notice if they’re using too much of your RAM and adjust how they work so they don’t ask for so much RAM
Maybe there are reasons, but it is not nearly good enough -- I frequently run out of RAM and encounter OOM kills (prefer not to deal with linux swap), usually requiring a reboot. I really wish that I could just set an upper limit on (e.g.) firefox RAM usage -- 8GB for example -- instead of its insistence on using all of the unused RAM minus a couple to several hundred MB, which does not leave enough room for memory usage spikes. There might even be a way to set this buried somewhere in the config parameters, but I could never find it. It must be technically possible to set some limit because otherwise the browser would not be able to maintain a somewhat consistent usage just below the total system RAM.