From: Andrew Morton <akpm@linux-foundation.org>
To: "Zhu, Lipeng" <lipeng.zhu@intel.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, pan.deng@intel.com, yu.ma@intel.com,
tianyou.li@intel.com, tim.c.chen@linux.intel.com
Subject: Re: [PATCH] fs/address_space: add alignment padding for i_map and i_mmap_rwsem to mitigate a false sharing.
Date: Sun, 2 Jul 2023 14:11:17 -0700 [thread overview]
Message-ID: <20230702141117.d9827596dea4ca9d6c5d1fd3@linux-foundation.org> (raw)
In-Reply-To: <20230628105624.150352-1-lipeng.zhu@intel.com>
On Wed, 28 Jun 2023 18:56:25 +0800 "Zhu, Lipeng" <lipeng.zhu@intel.com> wrote:
> When running UnixBench/Shell Scripts, we observed high false sharing
> for accessing i_mmap against i_mmap_rwsem.
>
> UnixBench/Shell Scripts are typical load/execute command test scenarios,
> the i_mmap will be accessed frequently to insert/remove vma_interval_tree.
> Meanwhile, the i_mmap_rwsem is frequently loaded. Unfortunately, they are
> in the same cacheline.
That sounds odd. One would expect these two fields to be used in
close conjunction, so any sharing might even be beneficial. Can you
identify in more detail what's actually going on in there?
> The patch places the i_mmap and i_mmap_rwsem in separate cache lines to avoid
> this false sharing problem.
>
> With this patch, on Intel Sapphire Rapids 2 sockets 112c/224t platform, based
> on kernel v6.4-rc4, the 224 parallel score is improved ~2.5% for
> UnixBench/Shell Scripts case. And perf c2c tool shows the false sharing is
> resolved as expected, the symbol vma_interval_tree_remove disappeared in
> cache line 0 after this change.
There can be many address_spaces in memory, so a size increase is a
concern. Is there anything we can do to minimize the cost of this?
next prev parent reply other threads:[~2023-07-02 21:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-28 10:56 [PATCH] fs/address_space: add alignment padding for i_map and i_mmap_rwsem to mitigate a false sharing Zhu, Lipeng
2023-07-02 21:11 ` Andrew Morton [this message]
2023-07-16 14:48 ` Zhu, Lipeng
2023-07-16 14:54 ` [PATCH v2] " Zhu, Lipeng
2023-07-16 14:56 ` Zhu, Lipeng
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=20230702141117.d9827596dea4ca9d6c5d1fd3@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lipeng.zhu@intel.com \
--cc=pan.deng@intel.com \
--cc=tianyou.li@intel.com \
--cc=tim.c.chen@linux.intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yu.ma@intel.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;
as well as URLs for NNTP newsgroup(s).