All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: NeilBrown <neilb@suse.de>, Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo	 <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
	Dave Chinner	 <david@fromorbit.com>
Subject: Re: [PATCH 5/7] nfsd: filecache: document the arbitrary limit on file-disposes-per-loop
Date: Mon, 27 Jan 2025 09:40:09 -0500	[thread overview]
Message-ID: <acb2c69ce2ef0f4fe0e2ba91397e9c9d3ef4aa89.camel@kernel.org> (raw)
In-Reply-To: <20250127012257.1803314-6-neilb@suse.de>

On Mon, 2025-01-27 at 12:20 +1100, NeilBrown wrote:
> Rather than having the bare number "8" use a named constant and explain
> the tradeoffs that lead to the choice.
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
>  fs/nfsd/filecache.c | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
> index 1e90da507152..7264faa57280 100644
> --- a/fs/nfsd/filecache.c
> +++ b/fs/nfsd/filecache.c
> @@ -493,6 +493,21 @@ nfsd_file_dispose_list_delayed(struct list_head *dispose)
>  	}
>  }
>  
> +/*
> + * Disposing of files can involve non-trivial work, and they
> + * can appear in batches.  So we don't want to try handling them
> + * all in one thread - if there are lots it would be better to allow
> + * several nfsd threads to handle them in parallel.
> + * On average one RPC request can create at most 1 file to be disposed
> + * so handling one each time around the nfsd loop should keep the list
> + * under control.  However there are often benefits of batching so
> + * 2 at a time will likely be more efficient than 1.  4 more so.
> + * We need to choose a number which will often handle all the files,
> + * but will allow other threads to help when the list gets long.
> + * The current choice is:
> + */
> +#define NFSD_FILE_DISPOSE_BATCH	8
> +
>  /**
>   * nfsd_file_net_dispose - deal with nfsd_files waiting to be disposed.
>   * @nn: nfsd_net in which to find files to be disposed.
> @@ -511,7 +526,8 @@ void nfsd_file_net_dispose(struct nfsd_net *nn)
>  		int i;
>  
>  		spin_lock(&l->lock);
> -		for (i = 0; i < 8 && !list_empty(&l->freeme); i++) {
> +		for (i = 0; i < NFSD_FILE_DISPOSE_BATCH &&
> +		     !list_empty(&l->freeme); i++) {
>  			struct nfsd_file *nf = list_first_entry(
>  				&l->freeme, struct nfsd_file, nf_lru);
>  

Thanks for doing this.

Reviewed-by: Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2025-01-27 14:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-27  1:20 [PATCH 0/7] nfsd: filecache: change garbage collection lists NeilBrown
2025-01-27  1:20 ` [PATCH 1/7] nfsd: filecache: remove race handling NeilBrown
2025-01-27 13:42   ` Jeff Layton
2025-01-27  1:20 ` [PATCH 2/7] nfsd: filecache: use nfsd_file_dispose_list() in nfsd_file_close_inode_sync() NeilBrown
2025-01-27  1:20 ` [PATCH 3/7] nfsd: filecache: move globals nfsd_file_lru and nfsd_file_shrinker to be per-net NeilBrown
2025-01-27  1:20 ` [PATCH 4/7] nfsd: filecache: change garbage collection list management NeilBrown
2025-01-27 14:15   ` Jeff Layton
2025-01-27  1:20 ` [PATCH 5/7] nfsd: filecache: document the arbitrary limit on file-disposes-per-loop NeilBrown
2025-01-27 14:40   ` Jeff Layton [this message]
2025-01-27  1:20 ` [PATCH 6/7] nfsd: filecache: change garbage collection to a timer NeilBrown
2025-01-27 14:39   ` Jeff Layton
2025-01-27  1:20 ` [PATCH 7/7] nfsd: filecache: give disposal lock a unique class name NeilBrown
2025-01-27 14:29   ` Chuck Lever
2025-01-27 14:40   ` Jeff Layton
2025-01-28  6:37 ` [PATCH 0/7] nfsd: filecache: change garbage collection lists Dave Chinner
2025-01-28 14:27   ` Chuck Lever
2025-01-28 16:05     ` Chuck Lever
2025-01-29 21:34   ` NeilBrown
2025-02-06  2:21     ` Dave Chinner
2025-02-06  3:04       ` NeilBrown
2025-02-06 14:35         ` Chuck Lever
2025-02-05 23:04 ` NeilBrown
2025-02-06  3:02   ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acb2c69ce2ef0f4fe0e2ba91397e9c9d3ef4aa89.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=chuck.lever@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.