[lkml]   [2009]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux killed Kenny, bastard!
    On Tue, 13 Jan 2009, Evgeniy Polyakov wrote:

    > It is a theory, not a practice. OOM-killer most of time starts from ssh,
    > database and lighttpd on the tested machines, when it could start in
    > the reverse order and do not touch ssh at all. Better not from daemon
    > itself, but its fastcgi spawned processes.

    In the unconstrained system-wide oom case, it scans each task on the
    system (which can take very long, ask SGI) and rates its badness scoring.
    When a memory-hogging task is identified, which you have complete control
    over in userspace by tuning /proc/pid/oom_adj, it attempts to kill a child
    first if it will allow for memory freeing without killing the parent.

    > I agree, that there are ways to tune the way oom-killer selects the
    > victim, and likely after hours of games this subtly will work for the
    > specified workload.

    It doesn't involve "hours of games," it is a very simple heuristic that
    you can easily tune to specify your preferences.

    What you're looking for with your patch is simply a way to specify an oom
    preference before the task has been forked, but that's simple to do with
    the current logic since oom_adj scores are inherited and preference is
    given to killing a child before parent.

    > What I propose is the simplest way for the most
    > commonly used case.

    No, procfs is the correct interface for tuning oom kill preferences and
    not by name parsing.

    With oom_adj scores, you have the ability to specify oom kill preferences
    within a cpuset or memory controller as well, whereas oom_victim_name is
    global and very costly when not found in select_bad_process().

    > It is a help for the admin and not the force to
    > invent complex machinery which will be error-prone and hard to debug
    > when eventually oom happens.

    It's very simple to debug the oom killer's decisions, which is why I
    introduced /proc/sys/vm/oom_dump_tasks.

    It also requires two expensive scans of the entire tasklist (I introduced
    /proc/sys/vm/oom_kill_allocating_task specifically to avoid _one_
    expensive scan) when oom_victim_name isn't found.

     \ /
      Last update: 2009-01-13 10:57    [W:0.035 / U:4.752 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site