linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: JonasZhou-oc <JonasZhou-oc@zhaoxin.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	CobeChen@zhaoxin.com, LouisQi@zhaoxin.com, JonasZhou@zhaoxin.com
Subject: Re: [PATCH] fs/address_space: move i_mmap_rwsem to mitigate a false sharing with i_mmap.
Date: Fri, 2 Feb 2024 19:32:36 +0000	[thread overview]
Message-ID: <Zb1DVNGaorZCDS7R@casper.infradead.org> (raw)
In-Reply-To: <Zb0EV8rTpfJVNAJA@casper.infradead.org>

On Fri, Feb 02, 2024 at 03:03:51PM +0000, Matthew Wilcox wrote:
> On Fri, Feb 02, 2024 at 05:34:07PM +0800, JonasZhou-oc wrote:
> > In the struct address_space, there is a 32-byte gap between i_mmap
> > and i_mmap_rwsem. Due to the alignment of struct address_space
> > variables to 8 bytes, in certain situations, i_mmap and
> > i_mmap_rwsem may end up in the same CACHE line.
> > 
> > While running Unixbench/execl, we observe high false sharing issues
> > when accessing i_mmap against i_mmap_rwsem. We move i_mmap_rwsem
> > after i_private_list, ensuring a 64-byte gap between i_mmap and
> > i_mmap_rwsem.
> 
> I'm confused.  i_mmap_rwsem protects i_mmap.  Usually you want the lock
> and the thing it's protecting in the same cacheline.  Why is that not
> the case here?

We actually had this seven months ago:

https://lore.kernel.org/all/20230628105624.150352-1-lipeng.zhu@intel.com/

Unfortunately, no argumentation was forthcoming about *why* this was
the right approach.  All we got was a different patch and an assertion
that it still improved performance.

We need to understand what's going on!  Please don't do the same thing
as the other submitter and just assert that it does.

  reply	other threads:[~2024-02-02 19:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-02  9:34 [PATCH] fs/address_space: move i_mmap_rwsem to mitigate a false sharing with i_mmap JonasZhou-oc
2024-02-02 10:18 ` Christian Brauner
2024-02-02 15:03 ` Matthew Wilcox
2024-02-02 19:32   ` Matthew Wilcox [this message]
2024-02-05  3:22     ` Dave Chinner
2024-02-05 23:28       ` Matthew Wilcox
2024-02-06 21:35         ` Dave Chinner
2024-02-06 23:33           ` Matthew Wilcox
2024-02-05  6:22     ` JonasZhou
2024-02-05 23:08       ` Matthew Wilcox
2024-02-06 13:06         ` Christian Brauner
2024-02-05 23:15       ` Dave Chinner
2024-03-06  6:16         ` JonasZhou
  -- strict thread matches above, loose matches on Subject: below --
2024-02-02  8:33 JonasZhou-oc
2024-02-02 16:20 ` Al Viro
2024-02-05 11:56 ` Christian Brauner

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=Zb1DVNGaorZCDS7R@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=CobeChen@zhaoxin.com \
    --cc=JonasZhou-oc@zhaoxin.com \
    --cc=JonasZhou@zhaoxin.com \
    --cc=LouisQi@zhaoxin.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).