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