The existence of OOM is one of the few really stupid things in Linux

Posted Nov 5, 2009 5:19 UTC (Thu) by mikov (guest, #33179)
In reply to: The existence of OOM is one of the few really stupid things in Linux by smoogen
Parent article: Toward a smarter OOM killer

It is not sloppiness. The OS cannot predict the future, so it can either be optimistic or pessimistic with memory. This is a very deliberate design choice. Turns out that in practice being optimistic is much much more efficient.

Here is what Linus had to say about that in 1995:
http://groups.google.com/group/comp.os.linux.development....

The fundamentals still apply.

The existence of OOM is one of the few really stupid things in Linux

Posted Nov 12, 2009 9:50 UTC (Thu) by rlhamil (guest, #6472) [Link]

While optimistic overcommit might be _statistically_ better, it's not deterministic enough
for my liking. And my liking is that everything other than /dev/random is _totally_
deterministic (neglecting external input of course).

(I'd argue that overcommit-by-default is an invitation to denial of service attack, and, if
likely victims were more or less predictable, might be a "covert channel" as well.)

Solaris doesn't do overcommit, but does also offer MAP_NORESERVE, so that individual
mmap() operations can opt out of a reserve, in which case a write to a private mapping
(copy-on-write from a file) can cause the process to receive SIGSEGV or SIGBUS; see

http://docs.sun.com/app/docs/doc/816-5167/mmap-2?l=en&...
(the online version of the mmap() man page for Solaris 10)

I think that all that's missing is:
* a system call to turn on or off similar behavior for heap and/or stack, and to
turn on or off _implicit_ MAP_NORESERVE on all private mappings for that process
and its subsequently forked children (reset on exec)
* a shared library feature to implement system policy specifying which executables
should be be subject to overcommit, with a settable default for all not explicitly specified
* an OS default of no overcommit
* no OOM killer needed

Distros could supply default policy that opted for overcommit on chronically hoggish
(and typically not critical to system integrity) apps such as browsers. People might e.g.
not mind their browser dying a few more times than it would anyway, but might be very
glad to be sure that their X server (desktop user) or database server process was safe from
nondeterministic behavior possibly triggered by another process.

That gets overcommit out of the OS, and pushes the decisions into user space. A process
could always override policy with the system calls, but it would have to know what it was
doing to do that.

The only limitation with implementing the defaults for an executable in the dynamic linker
is that it wouldn't be able to allow overcommit for static executables. If that was a serious
limitation, a new mechanism would be needed to push the policy settings into the kernel,
and execve() (or equivalents) would have to implement them, which is IMO more comprehensive
but otherwise uglier.