Comment by Agingcoder
3 years ago
That’s not what OP is saying. If your program gets shot by the oom killer your machine doesn’t lock up. OP is complaining that their machine locks up. What you’re describing is a reasonable scenario on Linux too that I’ve seen many times. On a mac things will go wrong when you run out of disk in general instead of running out of swap , but your process will fail eventually. Computing resources are finite. Sure there’s a bit more leeway ( assuming you’re not short on disk space … ) but given how the problem is described it’s very not clear that’s the issue.
I ´m an hpc engineer , specialize in performance work, have been using Linux since 1996, and also have a Mac. I like both. I understand these are not technical arguments, but my point is there are no easy answers when it comes to performance work. You need to measure, know exactly what’s going on, compare apples with apples, and then you can draw conclusions. In that particular case, there simply isn’t enough details to prove anything.
I guess I've just been unlucky because the OOM killer has always made bizarre decisions on my machines and killed something more critical than the runaway process (or just not worked at all, not sure what the deal was is that, I never get logs). Every time I looked it up online the replies were just "you need to enough RAM to run your process, idiot, you should never need swap, swap is bad"
If the normal case is that the OOM killer just kills the out-of-control process, then I forfeit my argument.
Yes that’s how it’s supposed to work. Supposed to, because as you’ve noticed there’s a long list of oom related patches in the kernel because it’s doesn’t always kill what it should kill !
Theory and practice unfortunately…