[lkml]   [2000]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: Avoiding OOM on overcommit...?
> > Alan, does it make sense, in ANY situation, to disable 
> overcommit? Because
> > AFAIK, a system without overcommit would always have to kill processes
> > before an equivalent overcommitting system would.
> >
> > It seems to me that this whole overcommit debate is just
> avoiding the real
> > problem, which is how to decide which tasks to kill.
> The whole point is: in a system without overcommit, a process is never
> killed for overcommitting.
> There's no issue about which process to kill because you never have to.

You are assuming that every bit of code is able to handle malloc
failures intelligently. Firstly there is a lot of code in the wild
that just doesn't expect malloc to fail (not unreasonably since the
author _knew_ he wasn't going to get anywhere near exhausting the
vm heap). Secondly the code paths that involve malloc failures are
some of the least tested. Thirdly the most common way of handling
a malloc failure is to simply kill the process, gracefully or otherwise.

So, if you use no-overcommit you either have a very specialized
system running carefully chosen software or you have a system which
will still fail but your only way of controlling the failure - trying
to keep it running as best you can then _choosing_ something "sensible"
to kill - has been removed.

Those who want no-overcommit are free to implement it and use it
of course, but it isn't the ultimate solution for a general purpose
OS that some people seem to think.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.079 / U:7.432 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site