From: Jeff Layton <jlayton@kernel.org>
To: lsf-pc@lists.linuxfoundation.org
Cc: NeilBrown <neilb@suse.de>, Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org
Subject: [LSF/MM/BPF TOPIC] allowing parallel directory modifications at the VFS layer
Date: Fri, 17 Jan 2025 12:26:38 -0500 [thread overview]
Message-ID: <f78f4a5e86c10d723fd60d51a52dd727924fed3a.camel@kernel.org> (raw)
We've hit a number of cases in testing recently where the parent's
i_rwsem ends up being the bottleneck in heavy parallel create
workloads. Currently we have to take the parent's inode->i_rwsem
exclusively when altering a directory, which means that any directory-
morphing operations in the same directory are serialized.
This is particularly onerous in the ->create codepath, since a
filesystem may have to do a number of blocking operations to create a
new file (allocate memory, start a transaction, etc.)
Neil recently posted this RFC series, which allows parallel directory
modifying operations:
https://lore.kernel.org/linux-fsdevel/20241220030830.272429-1-neilb@suse.de/
Al pointed out a number of problems in it, but the basic approach seems
sound. I'd like to have a discussion at LSF/MM about this.
Are there any problems with the basic approach? Are there other
approaches that might be better? Are there incremental steps we could
do pave the way for this to be a reality?
--
Jeff Layton <jlayton@kernel.org>
next reply other threads:[~2025-01-17 17:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-17 17:26 Jeff Layton [this message]
2025-01-18 1:06 ` [LSF/MM/BPF TOPIC] allowing parallel directory modifications at the VFS layer NeilBrown
2025-01-19 21:51 ` Dave Chinner
2025-01-19 22:25 ` NeilBrown
2025-01-20 11:55 ` Jeff Layton
2025-01-21 1:20 ` Dave Chinner
2025-01-21 13:04 ` Jeff Layton
2025-01-22 0:22 ` Dave Chinner
2025-01-22 1:04 ` NeilBrown
2025-02-03 17:19 ` Steve French
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=f78f4a5e86c10d723fd60d51a52dd727924fed3a.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linuxfoundation.org \
--cc=neilb@suse.de \
--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