From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 2/4] nfsd: NFSD_FILE_KEY_INODE only needs to find GC'ed entries
Date: Thu, 05 Jan 2023 09:29:37 -0500 [thread overview]
Message-ID: <cba5f0b6f13a314d78f7c767d47a7b6fac7e5ebc.camel@kernel.org> (raw)
In-Reply-To: <22E267B9-BA8C-46BA-A76E-A7A72FA5D9B3@oracle.com>
On Thu, 2023-01-05 at 14:18 +0000, Chuck Lever III wrote:
> Hi Jeff-
>
>
> > On Jan 5, 2023, at 7:15 AM, Jeff Layton <jlayton@kernel.org> wrote:
> >
> > Since v4 files are expected to be long-lived, there's little value in
> > closing them out of the cache when there is conflicting access.
>
> Seems like targeting long-lived nfsd_file items could actually
> be a hazardous behavior. Are you sure it's safe to leave it in
> stable kernels?
>
Basically it just means we end up doing more opens than are needed in
this situation.
The notifiers just unnecessarily unhash a nfsd_file in this case, even
though it doesn't have any chance of freeing it until the client issues
a CLOSE, due to the persistent references held by the stateids.
So, this really is just an optimization and not a "real bug".
>
> > Rename NFSD_FILE_KEY_INODE to NFSD_FILE_KEY_INODE_GC,
>
> I'd prefer to keep the name as it is. It's for searching for
> inodes, and adding the ".gc = true" to the search criteria is
> enough to show what you are looking for.
>
Ok.
>
> > and change the
> > comparator to also match the gc value in the key. Change both of the
> > current users of that key to set the gc value in the key to "true".
> >
> > Also, test_bit returns bool, AFAICT, so I think we're ok to drop the
> > !! from the condition later in the comparator.
>
> And I'd prefer that you leave this clean up for another patch.
>
Ok, I'll drop that hunk.
>
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > fs/nfsd/filecache.c | 14 +++++++++-----
> > 1 file changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
> > index 9fff1fa09d08..a67b22579c6e 100644
> > --- a/fs/nfsd/filecache.c
> > +++ b/fs/nfsd/filecache.c
> > @@ -78,7 +78,7 @@ static struct rhashtable nfsd_file_rhash_tbl
> > ____cacheline_aligned_in_smp;
> >
> > enum nfsd_file_lookup_type {
> > - NFSD_FILE_KEY_INODE,
> > + NFSD_FILE_KEY_INODE_GC,
> > NFSD_FILE_KEY_FULL,
> > };
> >
> > @@ -174,7 +174,9 @@ static int nfsd_file_obj_cmpfn(struct rhashtable_compare_arg *arg,
> > const struct nfsd_file *nf = ptr;
> >
> > switch (key->type) {
> > - case NFSD_FILE_KEY_INODE:
> > + case NFSD_FILE_KEY_INODE_GC:
> > + if (test_bit(NFSD_FILE_GC, &nf->nf_flags) != key->gc)
> > + return 1;
> > if (nf->nf_inode != key->inode)
> > return 1;
> > break;
> > @@ -187,7 +189,7 @@ static int nfsd_file_obj_cmpfn(struct rhashtable_compare_arg *arg,
> > return 1;
> > if (!nfsd_match_cred(nf->nf_cred, key->cred))
> > return 1;
> > - if (!!test_bit(NFSD_FILE_GC, &nf->nf_flags) != key->gc)
> > + if (test_bit(NFSD_FILE_GC, &nf->nf_flags) != key->gc)
> > return 1;
> > if (test_bit(NFSD_FILE_HASHED, &nf->nf_flags) == 0)
> > return 1;
> > @@ -681,8 +683,9 @@ static void
> > nfsd_file_queue_for_close(struct inode *inode, struct list_head *dispose)
> > {
> > struct nfsd_file_lookup_key key = {
> > - .type = NFSD_FILE_KEY_INODE,
> > + .type = NFSD_FILE_KEY_INODE_GC,
> > .inode = inode,
> > + .gc = true,
> > };
> > struct nfsd_file *nf;
> >
> > @@ -1057,8 +1060,9 @@ bool
> > nfsd_file_is_cached(struct inode *inode)
> > {
> > struct nfsd_file_lookup_key key = {
> > - .type = NFSD_FILE_KEY_INODE,
> > + .type = NFSD_FILE_KEY_INODE_GC,
> > .inode = inode,
> > + .gc = true,
> > };
> > bool ret = false;
> >
> > --
> > 2.39.0
> >
>
> --
> Chuck Lever
>
>
>
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2023-01-05 14:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-05 12:15 [PATCH 0/4] nfsd: filecache cleanups and optimizations Jeff Layton
2023-01-05 12:15 ` [PATCH 1/4] nfsd: don't open-code clear_and_wake_up_bit Jeff Layton
2023-01-05 12:15 ` [PATCH 2/4] nfsd: NFSD_FILE_KEY_INODE only needs to find GC'ed entries Jeff Layton
2023-01-05 14:18 ` Chuck Lever III
2023-01-05 14:29 ` Jeff Layton [this message]
2023-01-05 14:32 ` Chuck Lever III
2023-01-05 12:15 ` [PATCH 3/4] nfsd: don't kill nfsd_files because of lease break error Jeff Layton
2023-01-18 17:54 ` Jeff Layton
2023-01-18 18:45 ` Chuck Lever III
2023-01-05 12:15 ` [PATCH 4/4] nfsd: add some comments to nfsd_file_do_acquire Jeff Layton
2023-01-12 3:04 ` [PATCH 0/4] nfsd: filecache cleanups and optimizations Chuck Lever III
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=cba5f0b6f13a314d78f7c767d47a7b6fac7e5ebc.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
/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.