← Back to context

Comment by asveikau

13 years ago

I don't know what the author was thinking of specifically, but the OOM killer seems like a bit of a hack to me. I can think of situations where I'd rather have an allocation fail upfront predictably than be randomly killed by the system.

A lot of people seem to think you're screwed when you're out of memory and so think killing the process is acceptable, but I've worked on code bases where it's actually handled somewhat gracefully. (Although, on NT, if you run out of nonpaged pool you start to get weird, random I/O failures.)

but again, if it is just about the default behaviour which we debate, one can simply disable the overcommit

vm.overcommit_memory = 2

see https://www.kernel.org/doc/Documentation/vm/overcommit-accou...

  • And that was exactly the criticism, wasn't it? "Overcommit-by-default nonsense". I didn't write the original, just trying to parse it. (And with that aspect I kind of agree, it's a goofy behavior.)

    I guess there's another, somewhat social aspect of making that the default: everyone else coding on the platform assumes the behavior is the other way, so I suspect when you set that flag to off, your other software starts crashing on null pointer dereferences because no one thinks malloc can fail.