From: Christian Brauner <brauner@kernel.org>
To: chenzhiyin <zhiyin.chen@intel.com>
Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, nanhai.zou@intel.com
Subject: Re: [PATCH] fs.h: Optimize file struct to prevent false sharing
Date: Tue, 30 May 2023 10:50:42 +0200 [thread overview]
Message-ID: <20230530-wortbruch-extra-88399a74392e@brauner> (raw)
In-Reply-To: <20230530020626.186192-1-zhiyin.chen@intel.com>
On Mon, May 29, 2023 at 10:06:26PM -0400, chenzhiyin wrote:
> In the syscall test of UnixBench, performance regression occurred
> due to false sharing.
>
> The lock and atomic members, including file::f_lock, file::f_count
> and file::f_pos_lock are highly contended and frequently updated
> in the high-concurrency test scenarios. perf c2c indentified one
> affected read access, file::f_op.
> To prevent false sharing, the layout of file struct is changed as
> following
> (A) f_lock, f_count and f_pos_lock are put together to share the
> same cache line.
> (B) The read mostly members, including f_path, f_inode, f_op are
> put into a separate cache line.
> (C) f_mode is put together with f_count, since they are used
> frequently at the same time.
>
> The optimization has been validated in the syscall test of
> UnixBench. performance gain is 30~50%, when the number of parallel
> jobs is 16.
>
> Signed-off-by: chenzhiyin <zhiyin.chen@intel.com>
> ---
Sounds interesting, but can we see the actual numbers, please?
So struct file is marked with __randomize_layout which seems to make
this whole reordering pointless or at least only useful if the
structure randomization Kconfig is turned off. Is there any precedence
to optimizing structures that are marked as randomizable?
next prev parent reply other threads:[~2023-05-30 8:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-30 2:06 [PATCH] fs.h: Optimize file struct to prevent false sharing chenzhiyin
2023-05-30 8:50 ` Christian Brauner [this message]
2023-05-30 10:02 ` Amir Goldstein
2023-05-31 11:15 ` Christian Brauner
2023-05-31 1:55 ` Eric Biggers
2023-05-31 7:54 ` Christian Brauner
2023-06-01 9:24 ` chenzhiyin
2023-06-01 9:49 ` Christian Brauner
2023-06-01 10:06 ` Bernd Schubert
2023-06-05 12:58 ` Christian Brauner
2023-05-31 10:31 ` Chen, Zhiyin
2023-05-31 22:30 ` Dave Chinner
2023-06-01 10:47 ` Chen, Zhiyin
2023-06-02 0:47 ` Dave Chinner
2023-06-02 11:01 ` Chen, Zhiyin
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=20230530-wortbruch-extra-88399a74392e@brauner \
--to=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nanhai.zou@intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=zhiyin.chen@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).