Messages in this thread | | | Date | Wed, 3 Feb 2010 16:05:06 -0800 (PST) | From | David Rientjes <> | Subject | Re: 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.
| |