Re: [RFC 3/8] mm: page_alloc: do not lock up GFP_NOFS allocations upon OOM

[Michal Hocko <mhocko@kernel.org>]

On Wed 05-08-15 21:28:39, Tetsuo Handa wrote:
> Reduced to only linux-mm.
> 
> > From: Johannes Weiner <hannes@cmpxchg.org>
> > 
> > GFP_NOFS allocations are not allowed to invoke the OOM killer since
> > their reclaim abilities are severely diminished.  However, without the
> > OOM killer available there is no hope of progress once the reclaimable
> > pages have been exhausted.
> 
> Excuse me, but I still cannot understand. Why are !__GFP_FS allocations
> considered as "their reclaim abilities are severely diminished"?
> 
> It seems to me that not only GFP_NOFS allocation requests but also
> almost all types of memory allocation requests do not include
> __GFP_NO_KSWAPD flag.

__GFP_NO_KSWAPD is not to be used outside of very specific cases.

> Therefore, while a thread which called __alloc_pages_slowpath(GFP_NOFS)
> cannot reclaim FS memory, I assume that kswapd kernel threads which are
> woken up by the thread via wakeup_kswapd() via wake_all_kswapds() can
> reclaim FS memory by calling balance_pgdat(). Is this assumption correct?

yes.

> If the assumption is correct, when kswapd kernel threads returned from
> balance_pgdat() or got stuck inside reclaiming functions (e.g. blocked at
> mutex_lock() inside slab's shrinker functions), I think that the thread
> which called __alloc_pages_slowpath(GFP_NOFS) has reclaimed FS memory
> as if the thread called __alloc_pages_slowpath(GFP_KERNEL), and therefore
> the thread qualifies calling out_of_memory() as with __GFP_FS allocations.

You are missing an important point. We are talking about OOM situation
here. Which means that the background reclaim is not able to make
sufficient progress and neither is the direct reclaim. While the
GFP_IOFS requests are allowed to make a (V)FS activity which _might_
help GFP_NOFS is not by definition. And that is why this reclaim context
is less capable. Well to be more precise we do not perform IO (other
than the swapout) from the direct reclaim context because of the stack
restrictions so even GPF_IOFS is not _that_ strong but shrinkers are
still free to do metadata specific actions.
 
> > Don't risk hanging these allocations.  Leave it to the allocation site
> > to implement the fallback policy for failing allocations.
> 
> Are there memory pages which kswapd kernel threads cannot reclaim
> but __alloc_pages_slowpath(GFP_KERNEL) allocations can reclaim
> when __alloc_pages_slowpath(GFP_NOFS) allocations are hanging?

See above and have a look at the particular shrinkers code (e.g.
super_cache_scan).

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