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@xxxxxxxxx> 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@xxxxxxxxxxxxx/ > > 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?
