[lkml]   [2000]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] VM fix for 2.4.0-test9 & OOM handler
    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.



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

    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 12:39    [W:0.023 / U:0.164 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site