On Mon, 6 Dec 2021 11:19:22 +0800 Huangzhaoyang <huangzhaoyang@xxxxxxxxx> wrote:
> From: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx>
>
> 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.
