Re: Kernel 2.2.14 OOM killer strikes.

From: Horst von Brand (vonbrand@sleipnir.valparaiso.cl)
Date: Sat Jul 08 2000 - 18:31:49 EDT

  • Next message: Andrea Arcangeli: "Re: Kernel 2.2.14 OOM killer strikes."

    "Mike A. Harris" <mharris@meteng.on.ca> said:
    > On Fri, 7 Jul 2000, Derek Martin wrote:
    > >> the OOM condition 'logically'. That is the problem I believe, is
    > >> that the kernel needs to try and determine using logic which
    > >> process is the REAL bad guy. Next to impossible...

    > >Yeah I get it now. Though based on my (admittedly limited)
    > >understanding of the way the kernel currently decides to kill processes,
    > >that doesn't seem like it's any _worse_ a scenario, just not any better.
    > >
    > >> I'm dreaming up a daemon written in C for speed that:
    > >>
    > >> 1) Reads a config file of legal possible swapfile locations and
    > >> min/max sizes it can use, etc..
    > >> 2) Has configurable high/low watermarks to determine when to
    > >> create new swap space.

    It is _much_ easier just to set up said swap space in the first place. No
    kernel mods needed at all.

    [...]

    > In my case, a 'dynswap daemon' would give me a larger window of
    > time in which to 'catch' an OOM situation and use human brain
    > logic to kill processes. I could code the daemon to play a wav
    > file when a swap file is added, another when another swap is
    > added - increasing the 'defcon' number or alarmingness each time,
    > to warn me trouble is near. [...]

    Run a (tiny) daemon which periodically checks free space, and warns you
    when running low.

    -- 
    Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
    Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616
    

    - 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 Jul 08 2000 - 20:19:23 EDT