[lkml]   [2000]   [Mar]   [25]   [last100]   RSS Feed
Messages in this thread
SubjectRe: Endless overcommit memory thread.
On Sat, 25 Mar 2000, Linda Walsh wrote:
>"Richard B. Johnson" wrote:
>> Even if the perfect operating system kept some virtual RAM for
>> 'root' to log-in. It has no idea of what programs root would
>> want to execute. Eventually, it will fail with an out-of memory
>> condition.
> Having no idea of what programs root would execute doesn't mean
>you can't reserve sufficient memory for a shell, a ps and a kill.
>But if my machine runs out of processes and I can't log in -- I have
>little choice but to hit the RESET button.

You could use alt-sysrq to kill some tasks from the console, if you have
one. :-)

> By allowing 'overcommit', you end up in a situation where now your
>90M process touches the last of its memory -- and it isn't there, so....
>it SEGFAULT's because the memory mapper can't the address to a physical \

It gets killed because the sysadmin didn't put enough memory in the
machine. Which has nothing to do with overcommit...

> If you allow overcommit, you can have *either* the SEGFAULT behavior
>*or* the no-mem/locked out (process touches everything up front).
>If you disallow overcommit, you reduce the possible behaviors to 1.

You're confusing OOM situations with overcommit. OOM can happen without

>The problem is that suppose the process allocates it's memory -- with
>the 'overcommit' you have a system where it is hard to predict *what*
>will fail. Will it be a system process? A deamon? It's a
>low-integrity system because you can't figure out the behavior of
>failure in advance.

Predicting what will fail has nothing to do with overcommit. It depends on
the kernels OOM behavior.

> David's killing demon is fine for a user-space/level solution,
>but the kernel should default to the high-integrity option.

Which is Rik van Riel's patch, or something very much like it.


David Whysong
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page -

the body of a message to
Please read the FAQ at

 \ /
©2003-2011 Jasper Spaans