Messages in this thread | | | Date | Wed, 31 Mar 2010 09:57:14 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [PATCH] oom killer: break from infinite loop |
| |
On Tue, 30 Mar 2010 13:29:29 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > > index 0cb1ca4..9e89a29 100644 > > --- a/mm/oom_kill.c > > +++ b/mm/oom_kill.c > > @@ -510,8 +510,10 @@ retry: > > if (PTR_ERR(p) == -1UL) > > goto out; > > > > - if (!p) > > - p = current; > > + if (!p) { > > + read_unlock(&tasklist_lock); > > + panic("Out of memory and no killable processes...\n"); > > + } > > > > if (oom_kill_process(p, gfp_mask, 0, points, limit, mem, > > "Memory cgroup out of memory")) > > > > This actually does appear to be necessary but for a different reason: if > current is unkillable because it has OOM_DISABLE, for example, then > oom_kill_process() will repeatedly fail and mem_cgroup_out_of_memory() > will infinitely loop. > > Kame-san? >
When a memcg goes into OOM and it only has unkillable processes (OOM_DISABLE), we can do nothing. (we can't panic because container's death != system death.)
Because memcg itself has mutex+waitqueue for mutual execusion of OOM killer, I think infinite-loop will not be critical probelm for the whole system.
And, now, memcg has oom-kill-disable + oom-kill-notifier features. So, If a memcg goes into OOM and there is no killable process, but oom-kill is not disabled by memcg.....it means system admin's mis-configuraton.
He can stop inifite loop by hand, anyway. # echo 1 > ..../group_A/memory.oom_control
Thanks, -Kame
| |