Re: Avoiding OOM on overcommit...?

From: Khimenko Victor (khim@sch57.msk.ru)
Date: Sun Mar 26 2000 - 18:36:19 EST


In <38DE853A.D3953F38@empeg.com> John Ripley (john@empeg.com) wrote:
> 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.

Task is never, never, I repeat, NEVER is killed as result of overcommiting.
Task CAN be killed if there are not enough memory. With overcommit or without
overcommit (memory can be used by kernel itself and we'll end up with OOM).

> There's no issue about which process to kill because you never have to.

You always can get this problem. With overcommit or without overcommit.
Or you can just freeze all system in OOM -- usully MUCH worse then killing
some not-so-important tasks.

> The only exception is stack pages, which can be worked around by
> assigning appropriately sized stacks.

Heh. And who will track this "appropriate size" ? Who will redo programs with
shared memory to use complex and error-prone procedure to allocate chunks of
shared memory instead of one big few MiBs segment ?

In "ideal world" system without overcommiting will be more robust. In real
world without overcomminting you'll get MUCH less robust system due to lots
of stupid tricks in programs and error in those tricks not needed is overcommit
is allowed.

-
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