Yeah, but in the meantime you might actually notice that your system is slowing down, investigate and possibly fix the issue or intelligently kill the right process.

In practice, everything slows to an unusable crawl, and you hit the reset button because it's the fastest way of regaining control. IMO, earlyoom or similar is essential for general desktop use where memory load is unpredictable. Better to lose one process than lose all of them.

"The oom-killer generally has a bad reputation among Linux users. This may be part of the reason Linux invokes it only when it has absolutely no other choice. It will swap out the desktop environment, drop the whole page cache and empty every buffer before it will ultimately kill a process. At least that's what I think that it will do. I have yet to be patient enough to wait for it, sitting in front of an unresponsive system."

https://github.com/rfjakob/earlyoom

I guess Linux is different from macOS since I just had this situation last week. I wrote a quick app to generate a graphic and let it run in the background, noticed my machine was feeling a bit sluggish (but still totally usable for web browsing etc) and noticed my app had a memory leak and was using 100 GB of RAM and climbing on a 32 GB system. I could easily quit the app using the regular GUI.

NVMe SSDs are fantastic.

macOS has also has Jetsam (like the Linux OOM killer but much more aggressive) and swap-to-compression, so you're not as often swapping to disk as you'd think.

My app was leaking uncompressed 12 MP photo buffers and the swap file was over 70 GB, so in this case it was definitely swapping to hell

> In practice, everything slows to an unusable crawl

This is my experience as well. Maybe this could be mitigated with cgroup v2 by setting some processes to never swap so the user doesn't lose interaction with the system.

Unfortunately, that can happen to a much worse extent if swap is turned off. Linux will swap out all file-backed pages before invoking the OOM Killer, and since all user-space code is sitting in memory mapped pages, it will start swapping out code. And if you think waiting for disk to do a memory read is slow, imagine what waiting for disk to see what is the next available instruction can do to the system.

Is there a trick to reserve a percentage of actual RAM to be used for investigations and fixes? Because unless you already have a working shell open on the machine etc, are you going to wait 10 minutes for ssh to spawn a child, then 10 minutes for the shell to load and give it another 5 minutes for your ps to show?

BTDT, a lot of times. In the meantime I notice the system is slowing down, but I can't kill the guilty process because the system is too slow to ssh in. The ssh client times out while the ssh server is trying to obtain the pages it needs.

Swap is what turns the deficient OOM killer from a minor to a major problem.

I think the author clearly acknowledges that is a bad thing but argues that other advantages outweigh it.