fs: call inode_sb_list_add() outside of inode hash lock

As both locks are highly contended during significant inode churn,
holding the inode hash lock while waiting for the sb list lock
exacerbates the problem.

Why moving it out is safe: the inode at hand still has I_NEW set and
anyone who finds it through legitimate means waits for the bit to clear,
by which time inode_sb_list_add() is guaranteed to have finished.

This significantly drops hash lock contention for me when stating 20
separate trees in parallel, each with 1000 directories * 1000 files.

However, no speed up was observed as contention increased on the other
locks, notably dentry LRU.

Even so, removal of the lock ordering will help making this faster
later.

Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20250320004643.1903287-1-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
This commit is contained in:
Mateusz Guzik 2025-03-20 01:46:43 +01:00 committed by Christian Brauner
parent d5a05a5a44
commit c918f15420
No known key found for this signature in database
GPG Key ID: 91C61BC06578DCA2

View File

@ -1300,8 +1300,8 @@ again:
}
if (set && unlikely(set(inode, data))) {
inode = NULL;
goto unlock;
spin_unlock(&inode_hash_lock);
return NULL;
}
/*
@ -1313,14 +1313,14 @@ again:
hlist_add_head_rcu(&inode->i_hash, head);
spin_unlock(&inode->i_lock);
spin_unlock(&inode_hash_lock);
/*
* Add inode to the sb list if it's not already. It has I_NEW at this
* point, so it should be safe to test i_sb_list locklessly.
*/
if (list_empty(&inode->i_sb_list))
inode_sb_list_add(inode);
unlock:
spin_unlock(&inode_hash_lock);
return inode;
}
@ -1449,8 +1449,8 @@ again:
inode->i_state = I_NEW;
hlist_add_head_rcu(&inode->i_hash, head);
spin_unlock(&inode->i_lock);
inode_sb_list_add(inode);
spin_unlock(&inode_hash_lock);
inode_sb_list_add(inode);
/* Return the locked inode with I_NEW set, the
* caller is responsible for filling in the contents