On Tue, May 23, 2023 at 11:28:38AM +0200, Christian Brauner wrote: > On Tue, 09 May 2023 12:56:47 -0400, Kent Overstreet wrote: > > Because scalability of the global inode_hash_lock really, really > > sucks. > > > > 32-way concurrent create on a couple of different filesystems > > before: > > > > - 52.13% 0.04% [kernel] [k] ext4_create > > - 52.09% ext4_create > > - 41.03% __ext4_new_inode > > - 29.92% insert_inode_locked > > - 25.35% _raw_spin_lock > > - do_raw_spin_lock > > - 24.97% __pv_queued_spin_lock_slowpath > > > > [...] > > This is interesting completely independent of bcachefs so we should give > it some testing. > > I updated a few places that had outdated comments. > > --- > > Applied to the vfs.unstable.inode-hash branch of the vfs/vfs.git tree. > Patches in the vfs.unstable.inode-hash branch should appear in linux-next soon. > > Please report any outstanding bugs that were missed during review in a > new review to the original patch series allowing us to drop it. > > It's encouraged to provide Acked-bys and Reviewed-bys even though the > patch has now been applied. If possible patch trailers will be updated. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git > branch: vfs.unstable.inode-hash > > [22/32] vfs: inode cache conversion to hash-bl > https://git.kernel.org/vfs/vfs/c/e3e92d47e6b1 What, if anything, is blocking this? It is over 5 months now, I don't see it in master nor -next. To be clear there is no urgency as far as I'm concerned, but I did run into something which is primarily bottlenecked by inode hash lock and looks like the above should sort it out. Looks like the patch was simply forgotten. tl;dr can this land in -next please
