Re: [PATCH] mm,oom: Warn on racing with MMF_OOM_SKIP at task_will_free_mem(current).

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michal Hocko wrote:
> On Tue 26-09-17 20:27:40, Tetsuo Handa wrote:
> [...]
> > @@ -794,8 +794,10 @@ static bool task_will_free_mem(struct task_struct *task)
> >  	 * This task has already been drained by the oom reaper so there are
> >  	 * only small chances it will free some more
> >  	 */
> > -	if (test_bit(MMF_OOM_SKIP, &mm->flags))
> > +	if (test_bit(MMF_OOM_SKIP, &mm->flags)) {
> > +		WARN(1, "Racing OOM victim selection. Please report to linux-mm@xxxxxxxxx if you saw this warning from non-artificial workloads.\n");
> >  		return false;
> > +	}
> 
> This can easily happen even without a race. Just consider that OOM
> memory reserves got depleted.

What!? You said test_bit(MMF_OOM_SKIP, &mm->flags) == T can easily happen?
I was assuming that you believe that test_bit(MMF_OOM_SKIP, &mm->flags) == T
can't easily happen.

ALLOC_OOM was introduced in order to prevent OOM memory reserves from getting
completely depleted. I assume that you meant that OOM memory reserves got low
enough to fail ALLOC_OOM allocation attempt. But at the same time it means that
there is possibility that OOM memory reserves are not low enough to fail
ALLOC_OOM allocation attempt (but !ALLOC_OOM allocation attempt fails) when
this happens. Then, we are sure that we are already killing next OOM victims
needlessly because there is possibility that ALLOC_OOM allocation attempt can
succeed if we force it by "mm, oom:task_will_free_mem(current) should ignore
MMF_OOM_SKIP for once." patch. You prove that there is no reason we defer that
patch. We can revert that patch when we find better implementation in the future.

>                               I think that the existing oom report will
> tell us that the race happened by checking the mm counters.

I don't think so. Normal users won't dare to post their OOM reports in
order to ask us to judge whether the race happened. We won't be able to
judge whether the race happened unless all OOM reports are unconditionally
posted to ML. What a horrible idea...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux