Re: [PATCH] mm: mask DIRECT_RECLAIM in kswapd

[Andrew Morton <akpm@linux-foundation.org>]

On Mon,  6 Dec 2021 11:19:22 +0800 Huangzhaoyang <huangzhaoyang@gmail.com> wrote:

> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> 
> As the eg bellowing, using GFP_KERNEL could confuse the registered .releasepage
> or .shrinker functions when called in kswapd and have them acting wrongly.Mask
> __GFP_DIRECT_RECLAIM in kswapd.
> 
> eg,
> kswapd
>   shrink_page_list
>     try_to_release_page
>       __fscache_maybe_release_page
> 	...
>          if (!(gfp & __GFP_DIRECT_RECLAIM) || !(gfp & __GFP_FS)) {
>                  fscache_stat(&fscache_n_store_vmscan_busy);
>                  return false;
>          }

Well, we have thus far been permitting kswapd's memory allocations to
enter direct reclaim.  Forbidding that kernel-wide might be the right
thing to do, or might not be.  But disabling it kernel-wide because of
a peculiar hack in fscache is not good justification.

> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4083,7 +4083,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int highest_zoneidx)
>  	bool boosted;
>  	struct zone *zone;
>  	struct scan_control sc = {
> -		.gfp_mask = GFP_KERNEL,
> +		.gfp_mask = GFP_KERNEL & ~__GFP_DIRECT_RECLAIM,
>  		.order = order,
>  		.may_unmap = 1,
>  	};

Maybe hack the hack like this?

--- a/fs/fscache/page.c~a
+++ a/fs/fscache/page.c
@@ -126,8 +126,10 @@ page_busy:
 	 * sleeping on memory allocation, so we may need to impose a timeout
 	 * too. */
 	if (!(gfp & __GFP_DIRECT_RECLAIM) || !(gfp & __GFP_FS)) {
-		fscache_stat(&fscache_n_store_vmscan_busy);
-		return false;
+		if (!current_is_kswapd()) {
+			fscache_stat(&fscache_n_store_vmscan_busy);
+			return false;
+		}
 	}
 
 	fscache_stat(&fscache_n_store_vmscan_wait);
_

But please, do cc the fscache mailing list and maintainer when mucking
with these things.