Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps
From: Vlastimil Babka
Date: Mon Jul 18 2016 - 02:51:25 EST
On 07/18/2016 07:07 AM, Joonsoo Kim wrote:
On Thu, Jul 14, 2016 at 10:32:09AM +0200, Vlastimil Babka wrote:
On 07/14/2016 07:23 AM, Joonsoo Kim wrote:
I don't think there's a problem in the scenario? Kswapd will keep
being woken up and reclaim from the node lru. It will hit and free
any low zone pages that are on the lru, even though it doesn't
"balance for low zone". Eventually it will either satisfy the
constrained allocation by reclaiming those low-zone pages during the
repeated wakeups, or the low-zone wakeups will stop coming together
with higher-zone wakeups and then it will reclaim the low-zone pages
in a single low-zone wakeup. If the zone-constrained request is not
Yes, probability of this would be low.
allowed to fail, then it will just keep waking up kswapd and waiting
for the progress. If it's allowed to fail (i.e. not __GFP_NOFAIL),
but not allowed to direct reclaim, it goes "goto nopage" rather
quickly in __alloc_pages_slowpath(), without any waiting for
kswapd's progress, so there's not really much difference whether the
kswapd wakeup picked up a low classzone or not. Note the
Hmm... Even if allocation could fail, we should do our best to prevent
failure. Relying on luck isn't good idea to me.
But "Doing our best" has to have some sane limits. Allocation, that
cannot direct reclaim, already relies on luck. And we are not really
changing this. The allocation will "goto nopage" before kswapd can even
wake up and start doing something, regardless of classzone_idx used.
Thanks.
__GFP_NOFAIL but ~__GFP_DIRECT_RECLAIM is a WARN_ON_ONCE() scenario,
so definitely not common...
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>