Messages in this thread Patch in this message | ![/](/images/icornerl.gif) | | Date | Mon, 6 Dec 2021 17:23:40 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] mm: mask DIRECT_RECLAIM in kswapd |
| |
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.
| ![\](/images/icornerr.gif) |