Delaying the OOM killer [LWN.net]

Delaying the OOM killer

Posted Mar 10, 2011 12:41 UTC (Thu) by misiu_mp (guest, #41936)
Parent article: Delaying the OOM killer

"To Andrew Morton, instead, it looks like a kernel hack intended to work around user-space bugs, and he is not that thrilled by it."

I tend to agree. Wouldn't it be possible for a process that implements an OOM killer, to physically allocate the needed memory on startup? A proper out-of-memory handler should be limited to some (conservative) exact memory requirement.

The simplest way is to run malloc followed by a memset (for systems with overcommit). This would guarantee the pages are physically allocated or terminate/OOM at an early stage.
Now if such handler would use a kernel call or a system library that requires memory (which would be out of control of the handler's programmer), that call should simply not be made, or the said call be fixed in the kernel/library, possibly also by reserving memory for this. This behavior should also be documented. E.g. free() should never fail.

(Log in to post comments)

Delaying the OOM killer

Posted Mar 10, 2011 12:52 UTC (Thu) by johill (subscriber, #25196) [Link]

I might actually need mlockall(), but even that seems feasible.

Delaying the OOM killer

Posted Mar 10, 2011 13:07 UTC (Thu) by nix (subscriber, #2304) [Link]

It seems very dangerous to have anything whose purpose is to respond to out-of-memory conditions and *not* lock it into memory. (What we really need is a way to say 'make this process less overcommitted'. If you do that and then do all the work in a thread, or do a bit of mprotect() work, you can even avoid stack expansions causing OOM.)