On Tue, Dec 21, 2021 at 11:01 PM David Howells <dhowells@xxxxxxxxxx> wrote: > > Zhaoyang Huang <huangzhaoyang@xxxxxxxxx> wrote: > > > > > - if (!(gfp_flags & __GFP_DIRECT_RECLAIM) || !(gfp_flags & __GFP_FS)) > > > > + if (current_is_kswapd() || !(gfp_flags & __GFP_FS)) > > > > return false; > > > > wait_on_page_fscache(page); > > ... > > If the gfp flag here is used for judging kswapd context, I think the > > answer is yes as kswapd applied __GFP_DIRECT_RECLAIM. > > Now I come to look at applying it, I'm not sure whether this change is right. > > I don't know if kswapd has anything to do with it. The check is to see if > we're allowed to block at this point - and wait is just for the completion of > a DIO write to disk. > > It would seem like gfpflags_allow_blocking() is the right thing to call - and > that should use current_is_kswapd() if appropriate. > > David According to my understanding, this check is redundant according to current vmscan logic. For the allocation which deny __GFP_DIRECT_RECLAIM could NOT have the context reach here as there is no synchronous reclaiming. while kswapd also has __GFP_DIRECT_RECLAIM set and would also block on the page's release. > -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-cachefs
