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.
But nobody has ever seemed to care before. Because the inode hash just
isn't all that heavily used, since normal loads don't look up inodes
directly (they look up dentries, and you find the inodes off those -
and the *dentry* hash scales well thanks to both RCU and doing the
bucket lock thing).
So the fact that bcachefs cares makes me go "Why?"
Normal filesystems *never* call ilookup() and friends. Why does
bcachefs do it so much that you decided that you need to use a whole
other hashtable?
Linus
