David Whysong wrote:
> On Fri, 24 Mar 2000, Alan Cox wrote:
> >> The explanation is not the issue. The issue is having programs that
> >> act correctly (check malloc() returns, don't follow null pointers,
> >> etc.) fail in ways that are quite difficult for their programmers
> >> to prevent.
> >Indeed. And its completely valid to kill them off. Right now nobody has
> >a serious commercial requirement for non-overcommit on Linux.
>
> 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.
The only exception is stack pages, which can be worked around by
assigning appropriately sized stacks.
-- John Ripley, empeg Ltd.- 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:18 EST