KOSAKI Motohiro 0753ba01e1 mm: revert "oom: move oom_adj value"
The commit 2ff05b2b (oom: move oom_adj value) moveed the oom_adj value to
the mm_struct.  It was a very good first step for sanitize OOM.

However Paul Menage reported the commit makes regression to his job
scheduler.  Current OOM logic can kill OOM_DISABLED process.

Why? His program has the code of similar to the following.

	...
	set_oom_adj(OOM_DISABLE); /* The job scheduler never killed by oom */
	...
	if (vfork() == 0) {
		set_oom_adj(0); /* Invoked child can be killed */
		execve("foo-bar-cmd");
	}
	....

vfork() parent and child are shared the same mm_struct.  then above
set_oom_adj(0) doesn't only change oom_adj for vfork() child, it's also
change oom_adj for vfork() parent.  Then, vfork() parent (job scheduler)
lost OOM immune and it was killed.

Actually, fork-setting-exec idiom is very frequently used in userland program.
We must not break this assumption.

Then, this patch revert commit 2ff05b2b and related commit.

Reverted commit list
---------------------
- commit 2ff05b2b4e (oom: move oom_adj value from task_struct to mm_struct)
- commit 4d8b9135c3 (oom: avoid unnecessary mm locking and scanning for OOM_DISABLE)
- commit 8123681022 (oom: only oom kill exiting tasks with attached memory)
- commit 933b787b57 (mm: copy over oom_adj value at fork time)

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Paul Menage <menage@google.com>
Cc: David Rientjes <rientjes@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-18 16:31:13 -07:00
..
2009-07-12 12:22:34 -07:00
2009-06-11 21:36:14 -04:00
2009-07-12 12:24:07 -07:00
2009-06-11 21:36:01 -04:00
2009-07-12 12:22:34 -07:00
2009-07-12 12:22:34 -07:00
2009-06-24 08:15:24 -04:00
2009-07-14 12:28:43 -05:00
2009-06-17 00:36:36 -04:00
2009-07-12 12:22:34 -07:00
2009-07-12 12:22:34 -07:00
2009-07-12 12:22:34 -07:00
2009-07-12 12:22:34 -07:00
2009-07-12 12:22:34 -07:00
2009-07-12 12:22:34 -07:00
2009-07-12 12:22:34 -07:00
2009-05-22 18:40:59 +10:00
2009-07-10 19:18:59 -07:00
2009-07-12 12:22:34 -07:00
2009-06-15 21:44:43 -07:00
2009-08-12 08:21:39 -07:00
2009-07-12 12:22:34 -07:00
2009-06-15 21:44:43 -07:00
2009-06-11 21:36:13 -04:00
2009-08-18 16:31:13 -07:00
2009-06-11 21:36:12 -04:00
2009-07-30 17:31:23 +02:00
2009-07-12 12:22:34 -07:00
2009-06-11 21:36:07 -04:00
2009-07-12 12:22:34 -07:00
2009-06-17 00:36:37 -04:00
2009-07-12 12:22:34 -07:00
2009-06-18 13:03:46 -07:00
2009-06-30 18:55:58 -07:00
2008-12-31 18:07:43 -05:00
2009-01-03 11:45:54 -08:00
2009-07-01 11:14:28 -07:00
2009-07-12 12:22:34 -07:00
2009-07-12 12:22:34 -07:00
2009-06-11 21:36:06 -04:00
2009-06-18 13:03:41 -07:00
2009-07-12 12:22:34 -07:00
2009-03-31 23:00:26 -04:00
2009-08-07 14:38:29 -03:00
2009-06-11 21:36:07 -04:00
2009-07-14 12:34:17 +09:00
2009-04-07 08:31:16 -07:00
2009-04-20 23:02:52 -04:00
2009-02-18 15:37:53 -08:00
2009-06-11 21:36:02 -04:00