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."
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.
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.
> 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.
"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