From: Mike Snitzer <snitzer@kernel.org>
To: Anna Schumaker <anna.schumaker@oracle.com>
Cc: Jeff Layton <jlayton@kernel.org>,
linux-nfs@vger.kernel.org, Anna Schumaker <anna@kernel.org>,
Trond Myklebust <trondmy@hammerspace.com>
Subject: Re: nfs: avoid i_lock contention in nfs_clear_invalid_mapping
Date: Wed, 30 Oct 2024 16:03:24 -0400 [thread overview]
Message-ID: <ZyKRDKeAd0m19pt_@kernel.org> (raw)
In-Reply-To: <bedccb42-4e8a-4b9c-a0d4-982abb7a318e@oracle.com>
On Wed, Oct 30, 2024 at 03:51:44PM -0400, Anna Schumaker wrote:
> Hi Mike,
>
> On 10/18/24 5:37 PM, Mike Snitzer wrote:
> > On Fri, Oct 18, 2024 at 03:49:50PM -0400, Mike Snitzer wrote:
> >> On Fri, Oct 18, 2024 at 03:39:13PM -0400, Jeff Layton wrote:
> >>> On Fri, 2024-10-18 at 13:03 -0400, Mike Snitzer wrote:
> >>>> Multi-threaded buffered reads to the same file exposed significant
> >>>> inode spinlock contention in nfs_clear_invalid_mapping().
> >>>>
> >>>> Eliminate this spinlock contention by checking flags without locking,
> >>>> instead using smp_rmb and smp_load_acquire accordingly, but then take
> >>>> spinlock and double-check these inode flags.
> >>>>
> >>>> Also refactor nfs_set_cache_invalid() slightly to use
> >>>> smp_store_release() to pair with nfs_clear_invalid_mapping()'s
> >>>> smp_load_acquire().
> >>>>
> >>>> While this fix is beneficial for all multi-threaded buffered reads
> >>>> issued by an NFS client, this issue was identified in the context of
> >>>> surprisingly low LOCALIO performance with 4K multi-threaded buffered
> >>>> read IO. This fix dramatically speeds up LOCALIO performance:
> >>>>
> >>>> before: read: IOPS=1583k, BW=6182MiB/s (6482MB/s)(121GiB/20002msec)
> >>>> after: read: IOPS=3046k, BW=11.6GiB/s (12.5GB/s)(232GiB/20001msec)
> >>>>
> >>>> Fixes: 17dfeb911339 ("NFS: Fix races in nfs_revalidate_mapping")
> >>>> Signed-off-by: Mike Snitzer <snitzer@kernel.org>
> >>>> ---
> >>>> fs/nfs/inode.c | 19 ++++++++++++++-----
> >>>> 1 file changed, 14 insertions(+), 5 deletions(-)
> >>>>
> >>>> diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
> >>>> index 542c7d97b235..130d7226b12a 100644
> >>>> --- a/fs/nfs/inode.c
> >>>> +++ b/fs/nfs/inode.c
> >>>> @@ -205,12 +205,14 @@ void nfs_set_cache_invalid(struct inode *inode, unsigned long flags)
> >>>> nfs_fscache_invalidate(inode, 0);
> >>>> flags &= ~NFS_INO_REVAL_FORCED;
> >>>>
> >>>> - nfsi->cache_validity |= flags;
> >>>> + if (inode->i_mapping->nrpages == 0)
> >>>> + flags &= ~NFS_INO_INVALID_DATA;
> >>>>
> >>>> - if (inode->i_mapping->nrpages == 0) {
> >>>> - nfsi->cache_validity &= ~NFS_INO_INVALID_DATA;
> >>>> - nfs_ooo_clear(nfsi);
> >>>> - } else if (nfsi->cache_validity & NFS_INO_INVALID_DATA) {
> >>>> + /* pairs with nfs_clear_invalid_mapping()'s smp_load_acquire() */
> >>>> + smp_store_release(&nfsi->cache_validity, flags);
> >>>> +
> >>>
>
> I'm having some issues with non-localio NFS after applying this patch:
>
> - cthon basic tests fail with NFS v3
> - cthon general tests fail with NFS v4.1 and v4.2
> - xfstests generic/080, generic/472, generic/615, and generic/633 fail with NFS v4.1 and v4.2
> - xfstests generic/683, and generic/684 fail with NFS v4.2
>
> I think the problem is the call to smp_store_release(). It's overwriting nfsi->cache_validity
> with the value of 'flags', losing anything set there but not in 'flags'. Could we instead do
> something like:
> smp_store_release(&nfsi->cache_validity, nfsi->cache_validity | flags)
> ?
>
> Anna
Hi,
v2 addressed this issue like Jeff suggested with:
> >>>
> >>> flags |= nfsi->cache_validity;
> >>> smp_store_release(&nfsi->cache_validity, flags);
> >>
> >> Ah good catch, sorry about that, will fix.
I think you must not be using v2?
https://lore.kernel.org/all/20241018211541.42705-1-snitzer@kernel.org/
Jeff also provided his Reviewed-by for v2.
If you are using v2 that'll be weird (because I'm not seeing any
issues with xfstests, etc).
Thanks,
Mike
next prev parent reply other threads:[~2024-10-30 20:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-18 17:03 [PATCH] nfs: avoid i_lock contention in nfs_clear_invalid_mapping Mike Snitzer
2024-10-18 19:39 ` Jeff Layton
2024-10-18 19:49 ` Mike Snitzer
2024-10-18 21:37 ` Mike Snitzer
2024-10-30 19:51 ` Anna Schumaker
2024-10-30 20:03 ` Mike Snitzer [this message]
2024-10-30 20:08 ` Anna Schumaker
2024-10-30 20:11 ` Anna Schumaker
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=ZyKRDKeAd0m19pt_@kernel.org \
--to=snitzer@kernel.org \
--cc=anna.schumaker@oracle.com \
--cc=anna@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.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.