lkml.org 
[lkml]   [2000]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Avoiding OOM on overcommit...?
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2011 Jasper Spaans