On Wed 09-06-21 00:22:13, Tetsuo Handa wrote:
> On 2021/06/08 22:58, Michal Hocko wrote:
> > I do not see this message to be ever printed on 4.18 for memcg oom:
> > /* Found nothing?!?! Either we hang forever, or we panic. */
> > if (!oc->chosen && !is_sysrq_oom(oc) && !is_memcg_oom(oc)) {
> > dump_header(oc, NULL);
> > panic("Out of memory and no killable processes...\n");
> > }
> >
> > So how come it got triggered here? Is it possible that there is a global
> > oom killer somehow going on along with the memcg OOM? Because the below
> > stack clearly points to a memcg OOM and a new one AFAICS.
>
> 4.18 does print this message, and panic() will be called if global OOM
> killer invocation were in progress.
>
> 4.18.0-193.51.1.el8.x86_64 is doing
>
> ----------
> select_bad_process(oc);
> /* Found nothing?!?! */
> if (!oc->chosen) {
> dump_header(oc, NULL);
> pr_warn("Out of memory and no killable processes...\n");
> /*
> * If we got here due to an actual allocation at the
> * system level, we cannot survive this and will enter
> * an endless loop in the allocator. Bail out now.
> */
> if (!is_sysrq_oom(oc) && !is_memcg_oom(oc))
> panic("System is deadlocked on memory\n");
> }
> ----------
Ahh, OK. That would explain that. I have looked at 4.18 Vanilla kernel.
I do not have RHEL sources handy and neither checked the 4.18 stable
tree. Thanks for the clarification!
[...]
> Since dump_tasks() from dump_header(oc, NULL) does not exclude tasks
> which already has MMF_OOM_SKIP set, it is possible that the last OOM
> killable victim was already OOM killed but the OOM reaper failed to reclaim
> memory and set MMF_OOM_SKIP. (Well, maybe we want to exclude (or annotate)
> MMF_OOM_SKIP tasks when showing OOM victim candidates...)
Well, the allocating task was clearly alive and whether it has been
reaped or not is not all that important as it should force the charge as
an oom victim. This is actually the most puzzling part. Because the
allocating task either is not a preexisting OOM victim and therefore
could become one or it has been and should have skipped the memcg killer
altogether. But I fail to see how it could be missed completely while
looking for a victim.
--
Michal Hocko
SUSE Labs
