Re: Endless overcommit memory thread.

From: David Whysong (dwhysong@physics.ucsb.edu)
Date: Sat Mar 25 2000 - 19:45:10 EST

  • Next message: Tim Coleman: "Re: 2.3.99-prex-x pppd breaks"

    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/



    This archive was generated by hypermail 2b29 : Sat Mar 25 2000 - 19:46:53 EST