Re: [PATCH] Remove OOM killer from try_to_free_pages / all_unreclaimable braindamage

From: Werner Almesberger (wa_at_almesberger.net)
Date: 11/18/04

  • Next message: Giuseppe Sacco: "[PATCH] drivers/video/gbefb.c" 
    Date:	Wed, 17 Nov 2004 21:04:10 -0300
To: Chris Ross <chris@tebibyte.org>

    Chris Ross wrote:
    > The operating system has an
    > overview of all the memory and can see when a particular process is
    > basically making the machine unusable.

    The underlying hypothesis for suggesting explicitly flagging
    candidates for killing is of course that it doesn't see who
    exactly is misbehaving :-) Since this issue has been around for
    a nummber of years, I think it's fair to assume that the OOM
    killers indeed have a problem in that area.

    > It's quite likely that the
    > process causing the trouble doesn't know (or hasn't admitted) that it's
    > buggy and hasn't volunteered for early termination.

    I guess that depends a lot on your scenario. If your system is
    the typical undergrad mainframe where an army of students is
    hard at work trying to fork-bomb it out of existence, you're
    absolutely right.

    However, on a system where new programs are rarely added to the
    mix, the distinction should be easier. You can still get
    unexpected problems, e.g. vi trying to load a huge file, but
    you should be in a much better position to profile your system
    behaviour.

    It could of course be that this scenario is overly specific.

    > As this means the
    > kernel must be able to deal with a problematic process completely
    > irrespective of whether it has set "kill me" flag or not the flag
    > doesn't really buy you anything.

    I'd view it as an additional hint that killing that process is
    likely to help, a) because it may be the culprit, or b) because
    it is likely to hold lots of memory, and its death will not be
    mourned.

    I'm not suggesting to use this as a replacement for an adaptive
    OOM killer. The OOM killer could first make its pick among the
    suspects, and only if it runs out of them (or maybe if it finds
    overwhelming evidence that it's something else), then it would
    go after non-suspects.

    > There is the related case where no particular process is faulty as such
    > but the system as a whole can't cope with the demands being made.

    Yes, that's yet another scenario. Even then, having a list of
    things we can kill to give us some room would be useful.

    > The example I have in mind is on my machine when the daily cron
    > run over commits causing standard daemons such as ntpd to be killed to
    > make room. It would be preferable if the daemon was swapped out and just
    > didn't run for minutes, or even hours if need be, but was allowed to run
    > again once the system had settled down.

    Ah, now I understand why you'd want to swap. Interesting. Now,
    depending on the time if day, you have typically "interactive"
    processes, like your idle desktop, turn into "non-interactive"
    ones, which can then be subjected to swapping. Nice example
    against static classification :-)

    > So, the problem breaks down into three parts:
    >
    > i) When should the oom killer be invoked.
    > ii) How do we pick a victim process
    > iii) How can we deal with the process in the most useful manner

    iii) may also affect i). If you're going to swap, you don't want
    to wait until you're fighting for the last available page in the
    system.

    - Werner 

    -- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Giuseppe Sacco: "[PATCH] drivers/video/gbefb.c"

    Relevant Pages

    • Re: OOM-killer going crazy.
      ... free memory when the OOM killer activates in our situation. ... the memory hog because it's the kernel, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: help interpreting oom-killer output
      ... The system has gigs of memory, so I find this kind of odd. ... See that the DMA zone free count is equal to the "min" watermark. ... There have been a lot of changes since v2.6.10 in the OOM killer and reclaim ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Out of memory, but no OOM Killer? (2.6.9-ac11)
      ... > rsync seems to want lots of memory, yet the OOM killer doesn't strike. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 1/2 (repost)] mm: serialize OOM kill operations
      ... __alloc_pagesthis will cause the task to retry the memory allocation ... by the OOM killer's chosen victim. ... easily with the modified 2.6.9-based redhat kernel that I've been mostly ... I've been tinkering with the OOM killer lately because we're moving ...
      (Linux-Kernel)
    • Re: [RFC] [PATCH] Cgroup based OOM killer controller
      ... That's because the oom killer needs to kill a task that will allow future ... memory freeing on current->mems_allowed in these cases. ... It has really nothing with cpusets. ... allocation failure and invoking the oom killer. ...
      (Linux-Kernel)