diff options
author | KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> | 2010-03-10 15:22:32 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2010-03-12 15:52:37 -0800 |
commit | daaf1e68874c078a15ae6ae827751839c4d81739 (patch) | |
tree | 22ed2e28b1c4f0b714df680ffff6407e519c5c60 | |
parent | 1080d7a30304d03b1d9fd530aacd8aece2d702a2 (diff) | |
download | kernel_samsung_espresso10-daaf1e68874c078a15ae6ae827751839c4d81739.zip kernel_samsung_espresso10-daaf1e68874c078a15ae6ae827751839c4d81739.tar.gz kernel_samsung_espresso10-daaf1e68874c078a15ae6ae827751839c4d81739.tar.bz2 |
memcg: handle panic_on_oom=always case
Presently, if panic_on_oom=2, the whole system panics even if the oom
happend in some special situation (as cpuset, mempolicy....). Then,
panic_on_oom=2 means painc_on_oom_always.
Now, memcg doesn't check panic_on_oom flag. This patch adds a check.
BTW, how it's useful ?
kdump+panic_on_oom=2 is the last tool to investigate what happens in
oom-ed system. When a task is killed, the sysytem recovers and there will
be few hint to know what happnes. In mission critical system, oom should
never happen. Then, panic_on_oom=2+kdump is useful to avoid next OOM by
knowing precise information via snapshot.
TODO:
- For memcg, it's for isolate system's memory usage, oom-notiifer and
freeze_at_oom (or rest_at_oom) should be implemented. Then, management
daemon can do similar jobs (as kdump) or taking snapshot per cgroup.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Nick Piggin <npiggin@suse.de>
Reviewed-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-rw-r--r-- | Documentation/cgroups/memory.txt | 5 | ||||
-rw-r--r-- | Documentation/sysctl/vm.txt | 5 | ||||
-rw-r--r-- | mm/oom_kill.c | 2 |
3 files changed, 10 insertions, 2 deletions
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 268ab08..f8bc802 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -182,6 +182,8 @@ list. NOTE: Reclaim does not work for the root cgroup, since we cannot set any limits on the root cgroup. +Note2: When panic_on_oom is set to "2", the whole system will panic. + 2. Locking The memory controller uses the following hierarchy @@ -379,7 +381,8 @@ The feature can be disabled by NOTE1: Enabling/disabling will fail if the cgroup already has other cgroups created below it. -NOTE2: This feature can be enabled/disabled per subtree. +NOTE2: When panic_on_oom is set to "2", the whole system will panic in +case of an oom event in any cgroup. 7. Soft limits diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index fc5790d..6c7d18c 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -573,11 +573,14 @@ Because other nodes' memory may be free. This means system total status may be not fatal yet. If this is set to 2, the kernel panics compulsorily even on the -above-mentioned. +above-mentioned. Even oom happens under memory cgroup, the whole +system panics. The default value is 0. 1 and 2 are for failover of clustering. Please select either according to your policy of failover. +panic_on_oom=2+kdump gives you very strong tool to investigate +why oom happens. You can get snapshot. ============================================================= diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 35755a4..71d10bf 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -473,6 +473,8 @@ void mem_cgroup_out_of_memory(struct mem_cgroup *mem, gfp_t gfp_mask) unsigned long points = 0; struct task_struct *p; + if (sysctl_panic_on_oom == 2) + panic("out of memory(memcg). panic_on_oom is selected.\n"); read_lock(&tasklist_lock); retry: p = select_bad_process(&points, mem); |