From: Jeff Layton <jlayton@kernel.org>
To: cel@kernel.org, Neil Brown <neilb@suse.de>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: linux-nfs@vger.kernel.org, Dave Chinner <david@fromorbit.com>,
Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH v2 2/7] NFSD: Re-organize nfsd_file_gc_worker()
Date: Tue, 18 Feb 2025 14:59:42 -0500 [thread overview]
Message-ID: <a3393f7a210ee467749f3fabc7490fb17e3ef6e5.camel@kernel.org> (raw)
In-Reply-To: <20250218153937.6125-3-cel@kernel.org>
On Tue, 2025-02-18 at 10:39 -0500, cel@kernel.org wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
>
> Dave opines:
>
> IMO, there is no need to do this unnecessary work on every object
> that is added to the LRU. Changing the gc worker to always run
> every 2s and check if it has work to do like so:
>
> static void
> nfsd_file_gc_worker(struct work_struct *work)
> {
> - nfsd_file_gc();
> - if (list_lru_count(&nfsd_file_lru))
> - nfsd_file_schedule_laundrette();
> + if (list_lru_count(&nfsd_file_lru))
> + nfsd_file_gc();
> + nfsd_file_schedule_laundrette();
> }
>
> means that nfsd_file_gc() will be run the same way and have the same
> behaviour as the current code. When the system it idle, it does a
> list_lru_count() check every 2 seconds and goes back to sleep.
> That's going to be pretty much unnoticable on most machines that run
> NFS servers.
>
> Suggested-by: Dave Chinner <david@fromorbit.com>
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> fs/nfsd/filecache.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
> index 909b5bc72bd3..2933cba1e5f4 100644
> --- a/fs/nfsd/filecache.c
> +++ b/fs/nfsd/filecache.c
> @@ -549,9 +549,9 @@ nfsd_file_gc(void)
> static void
> nfsd_file_gc_worker(struct work_struct *work)
> {
> - nfsd_file_gc();
> + nfsd_file_schedule_laundrette();
> if (list_lru_count(&nfsd_file_lru))
> - nfsd_file_schedule_laundrette();
> + nfsd_file_gc();
> }
>
> static unsigned long
Given that it's a delayed workqueue job, it probably doesn't matter,
but why schedule the laundrette before doing the nfsd_file_gc() call?
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2025-02-18 19:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-18 15:39 [PATCH v2 0/7] nfsd: filecache: various fixes cel
2025-02-18 15:39 ` [PATCH v2 1/7] nfsd: filecache: remove race handling cel
2025-02-18 15:39 ` [PATCH v2 2/7] NFSD: Re-organize nfsd_file_gc_worker() cel
2025-02-18 19:59 ` Jeff Layton [this message]
2025-02-19 0:33 ` Dave Chinner
2025-02-19 1:20 ` NeilBrown
2025-02-19 14:01 ` Chuck Lever
2025-02-18 15:39 ` [PATCH v2 3/7] nfsd: filecache: use nfsd_file_dispose_list() in nfsd_file_close_inode_sync() cel
2025-02-18 15:39 ` [PATCH v2 4/7] nfsd: filecache: use list_lru_walk_node() in nfsd_file_gc() cel
2025-02-18 15:39 ` [PATCH v2 5/7] nfsd: filecache: introduce NFSD_FILE_RECENT cel
2025-02-18 15:39 ` [PATCH v2 6/7] nfsd: filecache: don't repeatedly add/remove files on the lru list cel
2025-02-18 20:27 ` Jeff Layton
2025-02-18 15:39 ` [PATCH v2 7/7] nfsd: filecache: drop the list_lru lock during lock gc scans cel
2025-02-18 20:51 ` Jeff Layton
2025-02-20 18:22 ` [PATCH v2 0/7] nfsd: filecache: various fixes 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=a3393f7a210ee467749f3fabc7490fb17e3ef6e5.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@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.