On Wed, May 17, 2023 at 09:15:34AM +1000, Dave Chinner wrote: > On Tue, May 16, 2023 at 12:17:04PM -0400, Kent Overstreet wrote: > > On Tue, May 16, 2023 at 05:45:19PM +0200, Christian Brauner wrote: > > > On Wed, May 10, 2023 at 02:45:57PM +1000, Dave Chinner wrote: > > > There's a bit of a backlog before I get around to looking at this but > > > it'd be great if we'd have a few reviewers for this change. > > > > It is well tested - it's been in the bcachefs tree for ages with zero > > issues. I'm pulling it out of the bcachefs-prerequisites series though > > since Dave's still got it in his tree, he's got a newer version with > > better commit messages. > > > > It's a significant performance boost on metadata heavy workloads for any > > non-XFS filesystem, we should definitely get it in. > > I've got an up to date vfs-scale tree here (6.4-rc1) but I have not > been able to test it effectively right now because my local > performance test server is broken. I'll do what I can on the old > small machine that I have to validate it when I get time, but that > might be a few weeks away.... > > git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git vfs-scale > > As it is, the inode hash-bl changes have zero impact on XFS because > it has it's own highly scalable lockless, sharded inode cache. So > unless I'm explicitly testing ext4 or btrfs scalability (rare) it's > not getting a lot of scalability exercise. It is being used by the > root filesytsems on all those test VMs, but that's about it... I think there's a bunch of perf tests being run on -next. So we can stuff it into a vfs.unstable.* branch and see what -next thinks of this performance wise.
