[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    [W:0.021 / U:34.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site