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 -- 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>