Re: [RFC PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection

[Hillf Danton <hdanton@sina.com>]

On Wed, 31 Jul 2019 13:08:44 +0200 Vlastimil Babka wrote:
> 
> I agree this is an improvement overall, but perhaps the patch does too
> many things at once. The reshuffle is one thing and makes sense. The
> change of the last return condition could perhaps be separate. Also
> AFAICS the ultimate result is that when nr_reclaimed == 0, the function
> will now always return false. Which makes the initial test for
> __GFP_RETRY_MAYFAIL and the comments there misleading. There will no
> longer be a full LRU scan guaranteed - as long as the scanned LRU chunk
> yields no reclaimed page, we abort.
> 
Thanks Vlastimil.

We can drop the test for __GFP_RETRY_MAYFAIL imo after observing no
regression produced by the reshuffle combined with dryrun detection
for reasons that
1) such a full lru scan is too expensive a cost for kswapd to pay for
balancing a node. The kthread you see drops the costly order when
appropriate. Which makes the helper in question false.

2) it has been a while otoh that reclaimers play game with neither
the costly order nor __GFP_RETRY_MAYFAIL taken into account, see
commit 2bb0f34fe3c1 ("mm: vmscan: do not iterate all mem cgroups for
global direct reclaim") for instance.

Hillf