>and you can be certain you're not going to be arbitrarily killed later for using the memory
Well, here's what makes designing the OOM-killer hard -- attempting to use memory that the
system doesn't have actually *doesn't* kill you, it just wakes up the OOM-killer and then it's
perfectly possible that the OOM-killer will go after someone else. Imagine a scenario where
one app allocates 99% of the system's memory (and not with some virtually allocated
overallocation bs, like they actually touch the pages or whatever), and then stops. Then you
try to run "ls", and it overflows that last 1% of memory and wakes up the OOM-killer. The
OOM-killer tries to identify and then attack the runaway giant process, not ls, even though ls
was the one who tried to get more memory.
So it doesn't actually help much for you, personally, to make sure your memory is not
overallocated -- if anything it will hurt, since it increases memory pressure overall and also
makes your process a bigger target. You can turn off overallocation globally, but that
doesn't necessarily help either, since in the scenario above it just means that ls (and every
other program you try to run) fails, while the runaway monster just sits there.
Google say you can disable the OOM killer on a per-process basis, though, which I hadn't