lkml.org 
[lkml]   [2010]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateWed, 3 Feb 2010 16:05:06 -0800 (PST)
FromDavid Rientjes <>
SubjectRe: Improving OOM killer
On Wed, 3 Feb 2010, Lubos Lunak wrote:

> > unsigned int badness(struct task_struct *p,
> > unsigned long totalram)
> > {
> > struct task_struct *child;
> > struct mm_struct *mm;
> > int forkcount = 0;
> > long points;
> >
> > task_lock(p);
> > mm = p->mm;
> > if (!mm) {
> > task_unlock(p);
> > return 0;
> > }
> > points = (get_mm_rss(mm) +
> > get_mm_counter(mm, MM_SWAPENTS)) * 1000 /
> > totalram;
> > task_unlock(p);
> >
> > list_for_each_entry(child, &p->children, sibling)
> > /* No lock, child->mm won't be dereferenced */
> > if (child->mm && child->mm != mm)
> > forkcount++;
> >
> > /* Forkbombs get penalized 10% of available RAM */
> > if (forkcount > 500)
> > points += 100;
>
> As far as I'm concerned, this is a huge improvement over the current code
> (and, incidentally :), quite close to what I originally wanted). I'd be
> willing to test it in few real-world desktop cases if you provide a patch.
>

There're some things that still need to be worked out, like discounting
hugetlb pages on each allowed node, respecting current's cpuset mems,
etc., but I think it gives us a good rough draft of where we might end up.
I did use the get_mm_rss() that you suggested, but I think it's more
helpful in the context of a fraction of total memory allowed so the other
heursitics (forkbomb, root tasks, nice'd tasks, etc) are penalizing the
points in a known quantity rather than a manipulation of that baseline.

Do you have any comments about the forkbomb detector or its threshold that
I've put in my heuristic? I think detecting these scenarios is still an
important issue that we need to address instead of simply removing it from
consideration entirely.


\
 
 \ /
  Last update: 2010-02-04 01:07    [from the cache]
©2003-2010