linux-kernel - Re: [GIT PULL] bcachefs changes for 6.12-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <xxxxcj5ijhcvluoqybzdrwfthigbq5t7r6q4nypbubr2rlcvst@hrhg5gxqmgyn>
Date: Mon, 23 Sep 2024 21:55:11 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Dave Chinner <david@...morbit.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Dave Chinner <dchinner@...hat.com>
Subject: Re: [GIT PULL] bcachefs changes for 6.12-rc1

On Tue, Sep 24, 2024 at 10:26:56AM GMT, Dave Chinner wrote:
> On Mon, Sep 23, 2024 at 03:56:50PM -0400, Kent Overstreet wrote:
> > On Mon, Sep 23, 2024 at 10:18:57AM GMT, Linus Torvalds wrote:
> > > On Sat, 21 Sept 2024 at 12:28, Kent Overstreet
> > > <kent.overstreet@...ux.dev> wrote:
> > > >
> > > > We're now using an rhashtable instead of the system inode hash table;
> > > > this is another significant performance improvement on multithreaded
> > > > metadata workloads, eliminating more lock contention.
> > > 
> > > So I've pulled this, but I reacted to this issue - what is the load
> > > where the inode hash table is actually causing issues?
> > > 
> > > Because honestly, the reason we're using that "one single lock" for
> > > the inode hash table is that nobody has ever bothered.
> > > 
> > > In particular, it *should* be reasonably straightforward (lots of
> > > small details, but not fundamentally hard) to just make the inode hash
> > > table be a "bl" hash - with the locking done per-bucket, not using one
> > > global lock.
> > 
> > Dave was working on that - he posted patches and it seemed like they
> > were mostly done, not sure what happened with those.
> 
> I lost interest in that patchset a long while ago. The last posting
> I did was largely as a community service to get the completed,
> lockdep and RTPREEMPT compatible version of the hashbl
> infrastructure it needed out there for other people to be able to
> easily push this forward if they needed it. That was here:
> 
> https://lore.kernel.org/linux-fsdevel/20231206060629.2827226-1-david@fromorbit.com/
> 
> and I posted it because Kent was asking about it because his
> attempts to convert the inode hash to use rhashtables wasn't
> working.
> 
> I've suggested multiple times since then when people have asked me
> about that patch set that they are free to pick it up and finish it
> off themselves. Unfortunately, that usually results in silence, a
> comment of "I don't have time for that", and/or they go off and hack
> around the issue in some other way....

Looking over that thread I'm not clear on what was missing - you
mentioned RTPREEMPT/lockdep but you had a patch for that, which looked
servicable enough?