I'll just say that earlyoom is much more bearable out-of-the-box than what this sounds like and much better than waiting for Linux to trigger the internal OOM killer (or trying to remember the SysRq key sequence to just trigger it. I always forget and don't have it close by when I need it :) ). I had to play around with the configuration a little to get it to match the conditions I could potentially get an OOM, but when it did reach it on my desktop, it would kill something like Slack, definitely not the whole X session. (FWIW, this happened when building a large Java project, that would burst with memory usage at certain stages of a build, on my computer that just has 16gb. Outside of managing OOM, it's something to play around with before giving up and just upping the RAM. :) )

Alt+SysRq+REISUB

Or, as a mnemonic: Reboot Even If System Utterly Borked*

*Being Irish, I prefer "Banjaxed" for the last word, personally.

Ah yeah, that :D But that's a full terminate process/filesystem sync/shutdown + restart ...

You got me to look it up: Alt-SysRq-F just for the kernel oom_killer ...

On ThinkPads, that's: Press Fn-Alt-S, then release Fn-S, then press the desired letter. Result from dmesg: "[154256.637037] sysrq: This sysrq operation is disabled." Bleh. Didn't work when you needed it :) Of course these can be enabled, but earlyoom is soo much easier than remembering the OOM dance or the REISUB dance (particularly if it is just an OOM :D)

> it will become so slow at to be totally unresponsive and the only thing you can do is to reboot.

It's been well over a decade since I've seen that kind of behavior. Storage devices became much lower latency and the kernel swapper got much smarter.

Can't confirm. I have more than 32GiB of memory and very fast storage and I see freezes more often than something being killed. The worst I saw was LUKS/dm-crypt being unable to allocate memory and slightly corrupting one of the mounted filesystems.

Linux Desktop in OOM situations is absolutely trash.

It still happens on an 8GiB laptop even with zram (I should probably buy a ram stick at this point).

Oh, definitely not my experience with 16 GB of RAM.

anecdotally, i've found that on a low-ram laptop having zram (i.e. compressed swap in ram) helps a lot, smoothing out the memory exhaustion. things start to get slower very gradually (as now swap churn means constant (de)compression rather than disk access), allowing you or the oom killer time to act.

I can also share this sentiment, though I have to add that unfortunately the kernel can still get into a state where it constantly churns pages to-from disk swap as well, freezing so hard that not even alt+printscr+f (oom killer) can react. Reisub works though. It seems to get fixed/reintroduced by version to version..

I found (no hard evidence though) that zswap behaves even more nicely, at least on a Raspberry Pi (and on top of that is easier to configure, it's just an on/off setting that can be done via procfs or boot argument, zswap.enabled=1).