Re: [PATCH] nfsd: add scheduling point in nfsd_file_gc()

[Chuck Lever <chuck.lever@oracle.com>]

On 1/5/25 6:11 PM, NeilBrown wrote:
> Under a high NFSv3 load with lots of different file being accessed The
> list_lru of garbage-collectable files can become quite long.
> 
> Asking lisT_lru_scan() to scan the whole list can result in a long
> period during which a spinlock is held and no scheduling is possible.
> This is impolite.
> 
> So only ask list_lru_scan() to scan 1024 entries at a time, and repeat
> if necessary - calling cond_resched() each time.
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
>   fs/nfsd/filecache.c | 17 ++++++++++++-----
>   1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
> index a1cdba42c4fa..e99a86798e86 100644
> --- a/fs/nfsd/filecache.c
> +++ b/fs/nfsd/filecache.c
> @@ -543,11 +543,18 @@ nfsd_file_gc(void)
>   {
>   	LIST_HEAD(dispose);
>   	unsigned long ret;
> -
> -	ret = list_lru_walk(&nfsd_file_lru, nfsd_file_lru_cb,
> -			    &dispose, list_lru_count(&nfsd_file_lru));
> -	trace_nfsd_file_gc_removed(ret, list_lru_count(&nfsd_file_lru));
> -	nfsd_file_dispose_list_delayed(&dispose);
> +	unsigned long cnt = list_lru_count(&nfsd_file_lru);
> +
> +	while (cnt > 0) {

Since @cnt is unsigned, it should be safe to use "while (cnt) {"

(I might use "total" and "remaining" here -- "cnt", when said aloud,
leaves me snickering).


> +		unsigned long num_to_scan = min(cnt, 1024UL);

I see long delays with fewer than 1024 items on the list. I might
drop this number by one or two orders of magnitude. And make it a
symbolic constant.

There's another naked integer (8) in nfsd_file_net_dispose() -- how does
that relate to this new cap? Should that also be a symbolic constant?


> +		ret = list_lru_walk(&nfsd_file_lru, nfsd_file_lru_cb,
> +				    &dispose, num_to_scan);
> +		trace_nfsd_file_gc_removed(ret, list_lru_count(&nfsd_file_lru));
> +		nfsd_file_dispose_list_delayed(&dispose);

I need to go back and review the function traces to see where the
delays add up -- to make sure rescheduling here, rather than at some
other point, is appropriate. It probably is, but my memory fails me
these days.


> +		cnt -= num_to_scan;
> +		if (cnt)
> +			cond_resched();

Another approach might be to poke the laundrette again and simply
exit here, but I don't feel strongly about that.


> +	}
>   }
>   
>   static void


-- 
Chuck Lever