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

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

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.

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?

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.

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

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