[lkml]   [2009]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Memory overcommit
    On Thu, 29 Oct 2009, Vedran Furac wrote:

    > But then you should rename OOM killer to TRIPK:
    > Totally Random Innocent Process Killer

    The randomness here is the order of the child list when the oom killer
    selects a task, based on the badness score, and then tries to kill a child
    with a different mm before the parent.

    The problem you identified in, however, is a
    forkbomb issue where the badness score should never have been so high for
    kdeinit4 compared to "test". That's directly proportional to adding the
    scores of all disjoint child total_vm values into the badness score for
    the parent and then killing the children instead.

    That's the problem, not using total_vm as a baseline. Replacing that with
    rss is not going to solve the issue and reducing the user's ability to
    specify a rough oom priority from userspace is simply not an option.

    > If you have OOM situation and Xorg is the first, that means it's leaking
    > memory badly and the system is probably already frozen/FUBAR. Killing
    > krunner in that situation wouldn't do any good. From a user perspective,
    > nothing changes, system is still FUBAR and (s)he would probably reboot
    > cursing linux in the process.

    It depends on what you're running, we need to be able to have the option
    of protecting very large tasks on production servers. Imagine if "test"
    here is actually a critical application that we need to protect, its
    not solely mlocked anonymous memory, but still kill if it is leaking
    memory beyond your approximate 2.5GB. How do you do that when using rss
    as the baseline?

     \ /
      Last update: 2009-10-29 20:57    [W:0.021 / U:0.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site