From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: kosaki.motohiro@jp.fujitsu.com,
Andrew Morton <akpm@linux-foundation.org>,
Rik van Riel <riel@redhat.com>, Nick Piggin <npiggin@suse.de>,
Oleg Nesterov <oleg@redhat.com>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm@kvack.org
Subject: Re: [patch 17/18] oom: add forkbomb penalty to badness heuristic
Date: Tue, 8 Jun 2010 20:41:57 +0900 (JST) [thread overview]
Message-ID: <20100608203146.765A.A69D9226@jp.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1006061527180.32225@chino.kir.corp.google.com>
> 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.
Today, I've test this patch. but I can't observed this works.
test way
prepare:
make 500M memory cgroup
console1:
run memtoy (consume 100M memory)
console2:
run forkbomb bash script ":(){ :|:& };:"
AFAIK, this is most typical forkbom. see http://en.wikipedia.org/wiki/Fork_bomb
each bash consume about 100KB and about 4000 bash process consume rest 400M.
oom_score list is here.
1) almost bash don't get forkbomb bonus at all
2) maxmumly root bash get 2x bonus and the score changed from 90 to 180.
but memtoy (100MB process) have score 25840. Still 143 times score
difference is there.
pid uid total_vs anonrss(kb) filerss(kb) oom_adj oom_score comm
-----------------------------------------------------------------------------------
[ 1865] 0 2880 448 1264 | 0 415 bash
[ 1887] 0 12076 284 1056 | 0 325 su
[ 1889] 1264 6313 992 1604 | 0 649 zsh
[ 1906] 1264 29317 102660 700 | 0 25840 memtoy
[ 2006] 0 26999 448 1376 | 0 442 bash
[ 2024] 0 36195 292 1160 | 0 352 su
[ 2025] 1268 26968 360 1380 | 0 435 bash
[ 5555] 1268 26968 364 300 | 0 166 bash
[ 5623] 1268 26968 364 300 | 0 166 bash
[ 5688] 1268 26968 364 300 | 0 166 bash
[ 5711] 1268 26968 364 300 | 0 166 bash
[ 5742] 1268 26968 364 300 | 0 166 bash
[ 5749] 1268 26968 364 300 | 0 166 bash
[ 5752] 1268 26968 364 388 | 0 188 bash
[ 5755] 1268 26968 364 300 | 0 166 bash
[ 5765] 1268 26968 364 300 | 0 166 bash
[ 5791] 1268 26968 364 300 | 0 166 bash
[ 5808] 1268 26968 364 300 | 0 166 bash
[ 5819] 1268 26968 364 324 | 0 172 bash
[ 5835] 1268 26968 364 300 | 0 166 bash
[ 5889] 1268 26968 364 300 | 0 166 bash
[ 5903] 1268 26968 364 300 | 0 166 bash
[ 5924] 1268 26968 364 424 | 0 197 bash
..... (continue to very much bash)
[10198] 1268 26968 368 20 | 0 97 bash
[10199] 1268 26968 368 20 | 0 97 bash
[10200] 1268 26968 368 20 | 0 97 bash
[10201] 1268 26968 368 20 | 0 97 bash
[10202] 1268 26968 368 20 | 0 97 bash
[10203] 1268 26968 368 20 | 0 97 bash
[10204] 1268 26968 368 20 | 0 97 bash
[10205] 1268 26968 368 20 | 0 97 bash
[10206] 1268 26968 368 20 | 0 97 bash
[10207] 1268 26968 364 20 | 0 96 bash
[10208] 1268 26968 364 20 | 0 96 bash
[10209] 1268 26968 368 20 | 0 97 bash
[10210] 1268 26968 368 20 | 0 97 bash
[10211] 1268 26968 368 20 | 0 97 bash
[10212] 1268 26968 368 20 | 0 97 bash
[10213] 1268 26968 368 20 | 0 97 bash
[10214] 1268 26968 368 20 | 0 97 bash
[10215] 1268 26968 368 20 | 0 97 bash
[10216] 1268 26968 368 20 | 0 97 bash
[10217] 1268 26968 368 20 | 0 97 bash
[10218] 1268 26968 368 20 | 0 97 bash
Memory cgroup out of memory: Kill process 1906 (memtoy) with score 25840 or sacrifice child
Killed process 1906 (memtoy) vsz:117268kB, anon-rss:102660kB, file-rss:700kB
At least, the patch author must define which problem is called as "forkbomb"
in this description.
I don't pulled this one.
--
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>
next prev parent reply other threads:[~2010-06-08 11:42 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-06 22:33 [patch 00/18] oom killer rewrite David Rientjes
2010-06-06 22:34 ` [patch 01/18] oom: check PF_KTHREAD instead of !mm to skip kthreads David Rientjes
2010-06-07 12:12 ` Balbir Singh
2010-06-07 19:50 ` David Rientjes
2010-06-08 19:33 ` Andrew Morton
2010-06-08 23:40 ` David Rientjes
2010-06-08 23:52 ` Andrew Morton
2010-06-06 22:34 ` [patch 02/18] oom: introduce find_lock_task_mm() to fix !mm false positives David Rientjes
2010-06-07 12:58 ` Balbir Singh
2010-06-07 13:49 ` Minchan Kim
2010-06-07 19:49 ` David Rientjes
2010-06-08 19:42 ` Andrew Morton
2010-06-08 20:14 ` Oleg Nesterov
2010-06-08 20:17 ` Oleg Nesterov
2010-06-08 21:34 ` Andrew Morton
2010-06-08 23:50 ` David Rientjes
2010-06-06 22:34 ` [patch 03/18] oom: dump_tasks use find_lock_task_mm too David Rientjes
2010-06-08 19:55 ` Andrew Morton
2010-06-09 0:06 ` David Rientjes
2010-06-06 22:34 ` [patch 04/18] oom: PF_EXITING check should take mm into account David Rientjes
2010-06-08 20:00 ` Andrew Morton
2010-06-06 22:34 ` [patch 05/18] oom: give current access to memory reserves if it has been killed David Rientjes
2010-06-08 11:41 ` KOSAKI Motohiro
2010-06-08 18:47 ` David Rientjes
2010-06-14 11:08 ` KOSAKI Motohiro
2010-06-08 20:12 ` Andrew Morton
2010-06-13 11:24 ` KOSAKI Motohiro
2010-06-08 20:08 ` Andrew Morton
2010-06-09 0:14 ` David Rientjes
2010-06-06 22:34 ` [patch 06/18] oom: avoid sending exiting tasks a SIGKILL David Rientjes
2010-06-08 11:41 ` KOSAKI Motohiro
2010-06-08 18:48 ` David Rientjes
2010-06-08 20:17 ` Andrew Morton
2010-06-08 20:26 ` Oleg Nesterov
2010-06-09 6:32 ` David Rientjes
2010-06-09 16:25 ` Oleg Nesterov
2010-06-09 19:44 ` David Rientjes
2010-06-09 20:14 ` Oleg Nesterov
2010-06-10 0:15 ` KAMEZAWA Hiroyuki
2010-06-10 1:21 ` Oleg Nesterov
2010-06-10 1:43 ` KAMEZAWA Hiroyuki
2010-06-10 1:51 ` Oleg Nesterov
2010-06-06 22:34 ` [patch 07/18] oom: filter tasks not sharing the same cpuset David Rientjes
2010-06-08 11:41 ` KOSAKI Motohiro
2010-06-08 18:51 ` David Rientjes
2010-06-08 19:27 ` Andrew Morton
2010-06-13 11:24 ` KOSAKI Motohiro
2010-07-02 22:35 ` Andrew Morton
2010-07-04 22:08 ` David Rientjes
2010-07-09 3:00 ` KOSAKI Motohiro
2010-06-08 20:23 ` Andrew Morton
2010-06-09 0:25 ` David Rientjes
2010-06-06 22:34 ` [patch 08/18] oom: sacrifice child with highest badness score for parent David Rientjes
2010-06-08 11:41 ` KOSAKI Motohiro
2010-06-08 18:53 ` David Rientjes
2010-06-08 20:33 ` Andrew Morton
2010-06-09 0:30 ` David Rientjes
2010-06-06 22:34 ` [patch 09/18] oom: select task from tasklist for mempolicy ooms David Rientjes
2010-06-08 11:41 ` KOSAKI Motohiro
2010-06-08 21:08 ` Andrew Morton
2010-06-08 21:17 ` Oleg Nesterov
2010-06-09 0:46 ` David Rientjes
2010-06-08 23:43 ` Andrew Morton
2010-06-09 0:40 ` David Rientjes
2010-06-06 22:34 ` [patch 10/18] oom: enable oom tasklist dump by default David Rientjes
2010-06-08 11:42 ` KOSAKI Motohiro
2010-06-08 18:56 ` David Rientjes
2010-06-08 21:13 ` Andrew Morton
2010-06-09 0:52 ` David Rientjes
2010-06-06 22:34 ` [patch 11/18] oom: avoid oom killer for lowmem allocations David Rientjes
2010-06-08 11:42 ` KOSAKI Motohiro
2010-06-08 21:19 ` Andrew Morton
2010-06-06 22:34 ` [patch 12/18] oom: extract panic helper function David Rientjes
2010-06-08 11:42 ` KOSAKI Motohiro
2010-06-06 22:34 ` [patch 13/18] oom: remove special handling for pagefault ooms David Rientjes
2010-06-08 11:42 ` KOSAKI Motohiro
2010-06-08 18:57 ` David Rientjes
2010-06-08 21:27 ` Andrew Morton
2010-06-06 22:34 ` [patch 14/18] oom: move sysctl declarations to oom.h David Rientjes
2010-06-08 11:42 ` KOSAKI Motohiro
2010-06-06 22:34 ` [patch 15/18] oom: remove unnecessary code and cleanup David Rientjes
2010-06-06 22:34 ` [patch 16/18] oom: badness heuristic rewrite David Rientjes
2010-06-08 11:41 ` KOSAKI Motohiro
2010-06-08 23:02 ` Andrew Morton
2010-06-13 11:24 ` KOSAKI Motohiro
2010-06-17 5:14 ` David Rientjes
2010-06-21 11:45 ` KOSAKI Motohiro
2010-06-21 20:47 ` David Rientjes
2010-06-30 9:26 ` KOSAKI Motohiro
2010-06-17 5:12 ` David Rientjes
2010-06-21 11:45 ` KOSAKI Motohiro
2010-06-08 22:58 ` Andrew Morton
2010-06-17 5:32 ` David Rientjes
2010-06-06 22:34 ` [patch 17/18] oom: add forkbomb penalty to badness heuristic David Rientjes
2010-06-08 11:41 ` KOSAKI Motohiro [this message]
2010-06-08 23:15 ` Andrew Morton
2010-06-06 22:35 ` [patch 18/18] oom: deprecate oom_adj tunable David Rientjes
2010-06-08 11:42 ` KOSAKI Motohiro
2010-06-08 19:00 ` David Rientjes
2010-06-08 23:18 ` Andrew Morton
2010-06-13 11:24 ` KOSAKI Motohiro
2010-06-17 3:36 ` David Rientjes
2010-06-21 11:45 ` KOSAKI Motohiro
2010-06-21 20:54 ` David Rientjes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100608203146.765A.A69D9226@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=oleg@redhat.com \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox