On Tue 17-02-15 21:23:26, Tetsuo Handa wrote: [...] > > Why do you omit out_of_memory() call for GFP_NOIO / GFP_NOFS allocations? Because they cannot perform any IO/FS transactions and that would lead to a premature OOM conditions way too easily. OOM killer is a _last resort_ reclaim opportunity not something that would happen just because you happen to be not able to flush dirty pages. > I can see "possible memory allocation deadlock in %s (mode:0x%x)" warnings > at kmem_alloc() in fs/xfs/kmem.c . > I think commit 9879de7373fcfb46 "mm: > page_alloc: embed OOM killing naturally into allocation slowpath" introduced > a regression and below one is the fix. > > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -2381,9 +2381,6 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order, > /* The OOM killer does not needlessly kill tasks for lowmem */ > if (high_zoneidx < ZONE_NORMAL) > goto out; > - /* The OOM killer does not compensate for light reclaim */ > - if (!(gfp_mask & __GFP_FS)) > - goto out; > /* > * GFP_THISNODE contains __GFP_NORETRY and we never hit this. > * Sanity check for bare calls of __GFP_THISNODE, not real OOM. So NAK to this. -- 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>