Re: How to handle TIF_MEMDIE stalls?

[Michal Hocko <mhocko@suse.cz>]

Ups, sorry I have missed the follow up emails in this thread. My filters
got crazy and the rest got sorted into a different mailbox.
Reading the rest now...

On Tue 17-02-15 15:37:20, Michal Hocko wrote:
> 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

-- 
Michal Hocko
SUSE Labs

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