Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler

From: Rik van Riel (riel@conectiva.com.br)
Date: Fri Oct 06 2000 - 16:31:11 EDT

  • Next message: Pavel Machek: "Re: 2.4.0-test9-pre8"

    On Fri, 6 Oct 2000, Byron Stanoszek wrote:
    > On Fri, 6 Oct 2000, Rik van Riel wrote:
    >
    > > 3. add the out of memory killer, which has been tuned with
    > > -test9 to be ran at exactly the right moment; process
    > > selection: "principle of least surprise" <== OOM handling
    >
    > In the OOM killer, shouldn't there be a check for PID 1 just to
    > enforce that INIT will not be the victim? Sure its total_vm
    > might be small, but if there was a memory leak in the kernel
    > somewhere, it might eventually become the target. I suppose, if
    > it ever were to become the victim, your system wouldn't be too
    > usable anyway...

    Indeed, if init is chosen for some reason, something really
    strange is going on and there's not much hope for rescueing
    it ;)

    > Can you give me your rationale for selecting 'nice' processes as
    > being badder?

    They are niced because the user thinks them a bit less
    important. This includes stuff like cron jobs that _just_
    push a system over the edge ...

    > Do you think it would be a good idea to scale the amount of
    > badness according to how nice the process is (a nice value of 20
    > could get the full *2, otherwise a smaller multiplier)?

    I've thought about this, but the algorithms used are so
    coarse that this makes little sense. Also, a nice+20
    process is often more "important" than the nice+4 cron
    job ... ;)

    > How about using the current process priority level instead of
    > nicety. If a process was deprioritized (or auto-niced) because
    > it was starting to eat up CPU time, AND its memory is abnormally
    > high, then should that be our #1 victim?

    Not really. In the first place, the dynamic priority changes
    so fast that it means almost nothing. Furthermore, once a process
    has used a lot of CPU time, killing it means you're potentially
    throwing away a lot of useful work that's been done.

    (same for a process which has been running a long time)

    > We also don't want to kill things like benchmarks either, but
    > hopefully they wouldn't start eating up more than the available
    > system memory.

    *grin*

    regards,

    Rik

    --
    "What you're running that piece of shit Gnome?!?!"
           -- Miguel de Icaza, UKUUG 2000
    

    http://www.conectiva.com/ http://www.surriel.com/

    - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/



    This archive was generated by hypermail 2b29 : Fri Oct 06 2000 - 16:33:54 EDT