> > 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.
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:19 EST