Re: [patch -mm 09/18] oom: add forkbomb penalty to badness heuristic

From: David Rientjes <rientjes@google.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>, Nick Piggin <npiggin@suse.de>,
	Oleg Nesterov <oleg@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	linux-mm@kvack.org
Subject: Re: [patch -mm 09/18] oom: add forkbomb penalty to badness heuristic
Date: Tue, 1 Jun 2010 11:57:10 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1006011157050.32024@chino.kir.corp.google.com> (raw)
In-Reply-To: <20100601163705.2460.A69D9226@jp.fujitsu.com>

On Tue, 1 Jun 2010, KOSAKI Motohiro wrote:

> > Add a forkbomb penalty for processes that fork an excessively large
> > number of children to penalize that group of tasks and not others.  A
> > threshold is configurable from userspace to determine how many first-
> > generation execve children (those with their own address spaces) a task
> > may have before it is considered a forkbomb.  This can be tuned by
> > altering the value in /proc/sys/vm/oom_forkbomb_thres, which defaults to
> > 1000.
> > 
> > When a task has more than 1000 first-generation children with different
> > address spaces than itself, a penalty of
> > 
> > 	(average rss of children) * (# of 1st generation execve children)
> > 	-----------------------------------------------------------------
> > 			oom_forkbomb_thres
> > 
> > is assessed.  So, for example, using the default oom_forkbomb_thres of
> > 1000, the penalty is twice the average rss of all its execve children if
> > there are 2000 such tasks.  A task is considered to count toward the
> > threshold if its total runtime is less than one second; for 1000 of such
> > tasks to exist, the parent process must be forking at an extremely high
> > rate either erroneously or maliciously.
> > 
> > Even though a particular task may be designated a forkbomb and selected as
> > the victim, the oom killer will still kill the 1st generation execve child
> > with the highest badness() score in its place.  The avoids killing
> > important servers or system daemons.  When a web server forks a very large
> > number of threads for client connections, for example, it is much better
> > to kill one of those threads than to kill the server and make it
> > unresponsive.
> > 
> > [oleg@redhat.com: optimize task_lock when iterating children]
> > Signed-off-by: David Rientjes <rientjes@google.com>
> 
> nack
> 

Why?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>