From: Christian Brauner <brauner@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [GIT PULL for v6.11] vfs inode
Date: Fri, 12 Jul 2024 15:58:04 +0200 [thread overview]
Message-ID: <20240712-vfs-inode-224711153dd2@brauner> (raw)
Hey Linus,
/* Summary */
This contains smaller performance improvements to inodes and dentries:
# inode:
- Add rcu based inode lookup variants. They avoid one inode hash lock acquire
in the common case thereby significantly reducing contention. We already
support RCU-based operations but didn't take advantage of them during inode
insertion.
Callers of iget_locked() get the improvement without any code changes.
Callers that need a custom callback can switch to iget5_locked_rcu() as e.g.,
did btrfs.
With 20 threads each walking a dedicated 1000 dirs * 1000 files directory
tree to stat(2) on a 32 core + 24GB ram vm:
before: 3.54s user 892.30s system 1966% cpu 45.549 total
after: 3.28s user 738.66s system 1955% cpu 37.932 total (-16.7%)
Long-term we should pick up the effort to introduce more fine-grained locking
and possibly improve on the currently used hash implementation.
- Start zeroing i_state in inode_init_always() instead of doing it in
individual filesystems. This allows us to remove an unneeded lock acquire in
new_inode() and not burden individual filesystems with this.
dcache:
- Move d_lockref out of the area used by RCU lookup to avoid cacheline ping
poing because the embedded name is sharing a cacheline with d_lockref.
- Fix dentry size on 32bit with CONFIG_SMP=y so it does actually end up with
128 bytes in total.
/* Testing */
clang: Debian clang version 16.0.6 (26)
gcc: (Debian 13.2.0-24)
All patches are based on v6.10-rc1 and have been sitting in linux-next.
No build failures or warnings were observed.
/* Conflicts */
Merge conflicts with other trees
================================
[1]: linux-next: manual merge of the vfs-brauner tree with the btrfs tree
https://lore.kernel.org/linux-next/ZnFyeNLLrEcX5_g0@sirena.org.uk
Merge conflicts with mainline
=============================
This causes a merge conflict with fs/bcachefs/fs.c. The gist is that
inode->i_state initialization in __bch2_new_inode() isn't needed anymore after
this is merged and that line needs to be deleted from that function.
The following changes since commit 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0:
Linux 6.10-rc1 (2024-05-26 15:20:12 -0700)
are available in the Git repository at:
git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-6.11.inode
for you to fetch changes up to dc99c0ff53f588bb210b1e8b3314c7581cde68a2:
fs: fix dentry size (2024-07-03 10:34:11 +0200)
Please consider pulling these changes from the signed vfs-6.11.inode tag.
Thanks!
Christian
----------------------------------------------------------------
vfs-6.11.inode
----------------------------------------------------------------
Christian Brauner (1):
fs: fix dentry size
Mateusz Guzik (7):
vfs: add rcu-based find_inode variants for iget ops
btrfs: use iget5_locked_rcu
xfs: preserve i_state around inode_init_always in xfs_reinit_inode
vfs: partially sanitize i_state zeroing on inode creation
xfs: remove now spurious i_state initialization in xfs_inode_alloc
bcachefs: remove now spurious i_state initialization
vfs: move d_lockref out of the area used by RCU lookup
fs/bcachefs/fs.c | 1 -
fs/btrfs/inode.c | 2 +-
fs/inode.c | 108 +++++++++++++++++++++++++++++++++++++------------
fs/xfs/xfs_icache.c | 5 ++-
include/linux/dcache.h | 9 ++++-
include/linux/fs.h | 7 +++-
6 files changed, 99 insertions(+), 33 deletions(-)
next reply other threads:[~2024-07-12 13:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-12 13:58 Christian Brauner [this message]
2024-07-15 20:34 ` [GIT PULL for v6.11] vfs inode pr-tracker-bot
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=20240712-vfs-inode-224711153dd2@brauner \
--to=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox