]> git.karo-electronics.de Git - karo-tx-linux.git/commit
oom-kill: remove boost_dying_task_prio()
authorKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Thu, 14 Apr 2011 22:22:13 +0000 (15:22 -0700)
committerGreg Kroah-Hartman <gregkh@suse.de>
Thu, 21 Apr 2011 21:32:44 +0000 (14:32 -0700)
commit9bf82fb0f4eb4035fae7c5436364e7b8b8b81e17
tree92fd1eae7488e111ac33a6cffd7662fe2eab304d
parent2fa669669e7646c45037b3d9a2bb9cc9a0c7f928
oom-kill: remove boost_dying_task_prio()

commit 341aea2bc48bf652777fb015cc2b3dfa9a451817 upstream.

This is an almost-revert of commit 93b43fa ("oom: give the dying task a
higher priority").

That commit dramatically improved oom killer logic when a fork-bomb
occurs.  But I've found that it has nasty corner case.  Now cpu cgroup has
strange default RT runtime.  It's 0!  That said, if a process under cpu
cgroup promote RT scheduling class, the process never run at all.

If an admin inserts a !RT process into a cpu cgroup by setting
rtruntime=0, usually it runs perfectly because a !RT task isn't affected
by the rtruntime knob.  But if it promotes an RT task via an explicit
setscheduler() syscall or an OOM, the task can't run at all.  In short,
the oom killer doesn't work at all if admins are using cpu cgroup and don't
touch the rtruntime knob.

Eventually, kernel may hang up when oom kill occur.  I and the original
author Luis agreed to disable this logic.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Luis Claudio R. Goncalves <lclaudio@uudg.org>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
mm/oom_kill.c