diff options
author | Dave Chinner <dchinner@redhat.com> | 2021-03-29 13:10:46 +1100 |
---|---|---|
committer | Kent Overstreet <kent.overstreet@linux.dev> | 2023-05-13 00:22:30 -0400 |
commit | 01f608f3ea6dde2ba02acd8e5dd1d0215840b168 (patch) | |
tree | 2dbdda4d3bc277d8a82fcb3d2c1edbdb8ab15c09 /include/linux/iomap.h | |
parent | fff2591c2a95f3a039f5603c9b9af479c930375a (diff) |
vfs: inode cache conversion to hash-bl
Because scalability of the global inode_hash_lock really, really
sucks.
32-way concurrent create on a couple of different filesystems
before:
- 52.13% 0.04% [kernel] [k] ext4_create
- 52.09% ext4_create
- 41.03% __ext4_new_inode
- 29.92% insert_inode_locked
- 25.35% _raw_spin_lock
- do_raw_spin_lock
- 24.97% __pv_queued_spin_lock_slowpath
- 72.33% 0.02% [kernel] [k] do_filp_open
- 72.31% do_filp_open
- 72.28% path_openat
- 57.03% bch2_create
- 56.46% __bch2_create
- 40.43% inode_insert5
- 36.07% _raw_spin_lock
- do_raw_spin_lock
35.86% __pv_queued_spin_lock_slowpath
4.02% find_inode
Convert the inode hash table to a RCU-aware hash-bl table just like
the dentry cache. Note that we need to store a pointer to the
hlist_bl_head the inode has been added to in the inode so that when
it comes to unhash the inode we know what list to lock. We need to
do this because the hash value that is used to hash the inode is
generated from the inode itself - filesystems can provide this
themselves so we have to either store the hash or the head pointer
in the inode to be able to find the right list head for removal...
Same workload after:
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org
Diffstat (limited to 'include/linux/iomap.h')
0 files changed, 0 insertions, 0 deletions