[lkml]   [2000]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
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 -
DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean