On Sat, 13 Feb 2010, Minchan Kim wrote: > > The oom killer is not the appropriate place for a kernel forkbomb policy > > to be implemented, you'd need to address that concern in the scheduler. > > I agree. but your's patch try to implement policy(avg rss of children < HZ) > in oom killer as well as detection. > so I pointed out that. That's not what's used, we detect whether a child should be included in the forkbomb count by checking for two traits: (i) it doesn't share an ->mm with the parent, otherwise it wouldn't free any memory unless the parent was killed as well, and (ii) its total runtime is less than a second since threads in forkbomb scenarios don't typically get any runtime. The _penalization_ is then the average rss of those children times how many times the count exceeds oom_forkbomb_thres. > I think if we want to implement it, we also consider above scenario. > As you said, it would be better to detect forkbom in scheduler. > Then, let's remove forkbomb detection in OOM killer. > Afterward, we can implement it in scheduler and can use it in OOM killer. > We're not enforcing a global, system-wide forkbomb policy in the oom killer, but we do need to identify tasks that fork a very large number of tasks to break ties with other tasks: in other words, it would not be helpful to kill an application that has been running for weeks because another application with the same or less memory usage has forked 1000 children and has caused an oom condition. That unfairly penalizes the former application that is actually doing work. Again, I'd encourage you to look at this as only a slight penalization rather than a policy that strictly needs to be enforced. If it were strictly enforced, it would be a prerequisite for selection if such a task were to exist; in my implementation, it is part of the heuristic. > > That doesn't work with Rik's example of a webserver that forks a large > > number of threads to handle client connections. It is _always_ better to > > kill a child instead of making the entire webserver unresponsive. > > In such case, admin have to handle it by oom_forkbom_thres. > Isn't it your goal? > oom_forkbomb_thres has a default value, which is 1000, so it should be enabled by default. > My suggestion is how handle buggy forkbomb processes which make > system almost hang by user's mistake. :) > I don't think you've given a clear description (or, even better, a patch) of your suggestion.