On Wed, Dec 06, 2023 at 11:58:44PM -0500, Kent Overstreet wrote: > On Wed, Dec 06, 2023 at 05:05:37PM +1100, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > Scalability of the global inode_hash_lock really sucks for > > filesystems that use the vfs inode cache (i.e. everything but XFS). > > Ages ago, we talked about (and I attempted, but ended up swearing at > inode lifetime rules) - conversion to rhashtable instead, which I still > believe would be preferable since that code is fully lockless (and > resizeable, of course). But it turned out to be a much bigger project... I don't think that the size of the has table is a big issue at the moment. We already have RCU lookups for the inode cache (find_inode_rcu() and find_inode_by_ino_rcu()) even before this patchset, so we don't need rhashtable for that. We still have to prevent duplicate inodes from being added to the cache due to racing inserts, so I think we still need some form of serialisation on the "lookup miss+insert" side. I've not thought about it further than that - the hash-bl removes the existing VFS contention points and the limitations move to filesystem internal algorithms once again. So until the filesystems can scale to much larger thread counts and put the pressure back on the VFS inode cache scalability, I don't see any need to try to do anything more complex or smarter... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
