Messages in this thread | | | Date | Tue, 27 Oct 2009 17:56:27 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [RFC][PATCH] oom_kill: avoid depends on total_vm and use real RSS/swap value for oom_score (Re: Memory overcommit |
| |
On Tue, 27 Oct 2009 17:52:43 +0900 Minchan Kim <minchan.kim@gmail.com> wrote:
> On Tue, 27 Oct 2009 17:33:08 +0900 > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > On Tue, 27 Oct 2009 17:14:41 +0900 > > Minchan Kim <minchan.kim@gmail.com> wrote: > > > > > On Tue, 27 Oct 2009 16:56:28 +0900 > > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > > > > > On Tue, 27 Oct 2009 16:45:26 +0900 > > > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > > /* > > > > > * After this unlock we can no longer dereference local variable `mm' > > > > > @@ -92,8 +93,13 @@ unsigned long badness(struct task_struct > > > > > */ > > > > > list_for_each_entry(child, &p->children, sibling) { > > > > > task_lock(child); > > > > > - if (child->mm != mm && child->mm) > > > > > - points += child->mm->total_vm/2 + 1; > > > > > + if (child->mm != mm && child->mm) { > > > > > + unsigned long cpoint; > > > > > + /* At considering child, we don't count swap */ > > > > > + cpoint = get_mm_counter(child->mm, anon_rss) + > > > > > + get_mm_counter(child->mm, file_rss); > > > > > + points += cpoint/2 + 1; > > > > > + } > > > > > task_unlock(child); > > > > > > > > BTW, I'd like to get rid of this code. > > > > > > > > Can't we use other techniques for detecting fork-bomb ? > > > > > > > > This check can't catch following type, anyway. > > > > > > > > fork() > > > > -> fork() > > > > -> fork() > > > > -> fork() > > > > .... > > > > > > > > but I have no good idea. > > > > What is the difference with task-launcher and fork bomb()... > > > > > > > > > > I think it's good as-is. > > > Kernel is hard to know it by effiecient method. > > > It depends on applications. so Doesnt's task-launcher > > > like gnome-session have to control his oom_score? > > > > > > Welcome to any ideas if kernel can do it well. > > > > > Hmmm, check system-wide fork/sec and fork-depth ? Maybe not difficult to calculate.. > > Yes. We can do anything to achieve the goal in kernel. > Maybe check the time or fork-depth counting. > What I have a concern is how we can do it nicely if it is a serious > problem in kernel. ;) > yes...only the user knows whether user is wrong, finally. Especially in case of memory leak.
> I think most of program which have many child are victims of OOM killing. > It make sense to me. There is some cases to not make sense like task-launcher. > So I think if task-launcher which is very rare and special program can change > oom_adj by itself, it's good than thing that add new heuristic in kernel. > > It's just my opinon. :) > I know KDE already adjsut oom_adj for their 3.5 release ;) Okay, concentrate on avoiding total_vm issue for a while.
Thanks, -Kame
| |