lkml.org 
[lkml]   [2000]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 \
>object?

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
overcommit.

>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.

Dave

David Whysong dwhysong@physics.ucsb.edu
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
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 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