From: cel@kernel.org
To: Neil Brown <neilb@suse.de>, Jeff Layton <jlayton@kernel.org>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: <linux-nfs@vger.kernel.org>
Subject: [PATCH v1] nfsd: drop the lock during filecache LRU scans
Date: Thu, 9 Jan 2025 09:24:37 -0500 [thread overview]
Message-ID: <20250109142438.18689-1-cel@kernel.org> (raw)
From: NeilBrown <neilb@suse.de>
Under a high NFSv3 load with lots of different file being accessed,
the LRU list 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, blocking the addition and
removal of LRU items.
So ask list_lru_scan() to scan only a few entries at a time, and
repeat until the scan is complete.
Fixes: edead3a55804 ("NFSD: Fix the filecache LRU shrinker")
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
fs/nfsd/filecache.c | 14 ++++++++++----
fs/nfsd/filecache.h | 6 ++++++
2 files changed, 16 insertions(+), 4 deletions(-)
Updated version of Neil's patch to break up filecache LRU scans.
This can be backported to LTS kernels -- a Fixes tag has been
proposed.
Subsequent work can replace the list_lru mechanism. That would
be more substantial and thus more challenging to backport.
There are two concerns here:
- The number of items in the LRU can now change while this loop is
operating. We might need a "if (!ret) break;" or some other exit
condition to prevent an infinite loop.
- The list_lru_walk() always starts at the tail of the LRU, rather
than picking up where it left off. So it might only visit the
same handful of items on the list repeatedly, reintroducing the
bug fixed by edead3a55804.
diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
index a1cdba42c4fa..fcd751cb7c76 100644
--- a/fs/nfsd/filecache.c
+++ b/fs/nfsd/filecache.c
@@ -541,13 +541,19 @@ nfsd_file_lru_cb(struct list_head *item, struct list_lru_one *lru,
static void
nfsd_file_gc(void)
{
+ unsigned long remaining = list_lru_count(&nfsd_file_lru);
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);
+ while (remaining > 0) {
+ unsigned long num_to_scan = min(remaining, NFSD_FILE_GC_BATCH);
+
+ 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);
+ remaining -= num_to_scan;
+ }
}
static void
diff --git a/fs/nfsd/filecache.h b/fs/nfsd/filecache.h
index d5db6b34ba30..463bd60b98b4 100644
--- a/fs/nfsd/filecache.h
+++ b/fs/nfsd/filecache.h
@@ -3,6 +3,12 @@
#include <linux/fsnotify_backend.h>
+/*
+ * Limit the time that the list_lru_one lock is held during
+ * an LRU scan.
+ */
+#define NFSD_FILE_GC_BATCH (32UL)
+
/*
* This is the fsnotify_mark container that nfsd attaches to the files that it
* is holding open. Note that we have a separate refcount here aside from the
--
2.47.0
next reply other threads:[~2025-01-09 14:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 14:24 cel [this message]
2025-01-09 14:24 ` [PATCH v1] nfsd: drop the lock during filecache LRU scans cel
2025-01-09 23:49 ` NeilBrown
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=20250109142438.18689-1-cel@kernel.org \
--to=cel@kernel.org \
--cc=dai.ngo@oracle.com \
--cc=jlayton@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox