summaryrefslogtreecommitdiff
path: root/fs/stack.c
diff options
context:
space:
mode:
authorMateusz Guzik <mjguzik@gmail.com>2025-03-20 01:46:43 +0100
committerChristian Brauner <brauner@kernel.org>2025-03-20 13:06:51 +0100
commitc918f15420e336a964f8f12d9c1134859a147d42 (patch)
treed0957746b36e6047f4862bd665f6bb81e075bb14 /fs/stack.c
parentd5a05a5a44a983ead5c57673af2c5bcfd2f0d3e9 (diff)
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>
Diffstat (limited to 'fs/stack.c')
0 files changed, 0 insertions, 0 deletions