On Tue, 30 Mar 2010 13:29:29 -0700 (PDT)
David Rientjes <rientjes@xxxxxxxxxx> 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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>