Thread (10 messages) 10 messages, 2 authors, 2021-07-27

Re: [PATCH v8 0/5] kernfs: proposed locking and concurrency improvement

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2021-07-27 10:03:08
Also in: linux-fsdevel

On Fri, Jul 16, 2021 at 05:28:13PM +0800, Ian Kent wrote:
There have been a few instances of contention on the kernfs_mutex during
path walks, a case on very large IBM systems seen by myself, a report by
Brice Goglin and followed up by Fox Chen, and I've since seen a couple
of other reports by CoreOS users.

The common thread is a large number of kernfs path walks leading to
slowness of path walks due to kernfs_mutex contention.

The problem being that changes to the VFS over some time have increased
it's concurrency capabilities to an extent that kernfs's use of a mutex
is no longer appropriate. There's also an issue of walks for non-existent
paths causing contention if there are quite a few of them which is a less
common problem.

This patch series is relatively straight forward.

All it does is add the ability to take advantage of VFS negative dentry
caching to avoid needless dentry alloc/free cycles for lookups of paths
that don't exit and change the kernfs_mutex to a read/write semaphore.

The patch that tried to stay in VFS rcu-walk mode during path walks has
been dropped for two reasons. First, it doesn't actually give very much
improvement and, second, if there's a place where mistakes could go
unnoticed it would be in that path. This makes the patch series simpler
to review and reduces the likelihood of problems going unnoticed and
popping up later.

Changes since v7:
- remove extra tab in helper kernfs_dir_changed.
- fix thinko adding an unnecessary kernfs_inc_rev() in kernfs_rename_ns().
Thanks for sticking with this, I've applied this to my testing branch
and let's see how 0-day does with it :)

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help