Re: How to handle TIF_MEMDIE stalls?

Michal Hocko
2015-02-17T14:37:24Z

On Mon 09-02-15 20:44:16, Tetsuo Handa wrote:
> Hello.
>
> Today I tested Linux 3.19 and noticed unexpected behavior (A) (B)
> shown below.
>
> (A) The order-0 __GFP_WAIT allocation fails immediately upon OOM condition
> despite we didn't remove the
>
> /*
> * In this implementation, order <= PAGE_ALLOC_COSTLY_ORDER
> * means __GFP_NOFAIL, but that may not be true in other
> * implementations.
> */
> if (order <= PAGE_ALLOC_COSTLY_ORDER)
> return 1;
>
> check in should_alloc_retry(). Is this what you expected?

The code before 9879de7373fc (mm: page_alloc: embed OOM killing
naturally into allocation slowpath) was looping on this kind of
allocation even though GFP_NOFS didn't trigger OOM killer. This change
was not intentional I guess but it makes sense on its own. We shouldn't
simply loop in a hope that something happens and we finally make a
progress.

Failing __GFP_WAIT allocation is perfectly fine IMO. Why do you think
this is a problem?

Btw. this has nothing to do with TIF_MEMDIE and it would be much better
to discuss it in a separate thread...

> (B) When coredump to pipe is configured, the system stalls under OOM
> condition due to memory allocation by coredump's reader side.
> How should we handle this "expected to terminate shortly but unable
> to terminate due to invisible dependency" case? What approaches
> other than applying timeout on coredump's writer side are possible?
> (Running inside memory cgroup is not an answer which I want.)

This is really nasty and we have discussed that with Oleg some time
ago. We have SIGNAL_GROUP_COREDUMP which prevents the OOM killer
from selecting the task. The issue seems to be that OOM killer might
inherently race with setting the flag. I have no idea what to do about
this, unfortunately.
Oleg?
--
Michal Hocko
SUSE Labs