summaryrefslogtreecommitdiff
path: root/include/linux/iomap.h
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2021-03-29 13:10:46 +1100
committerKent Overstreet <kent.overstreet@linux.dev>2023-05-13 00:22:30 -0400
commit01f608f3ea6dde2ba02acd8e5dd1d0215840b168 (patch)
tree2dbdda4d3bc277d8a82fcb3d2c1edbdb8ab15c09 /include/linux/iomap.h
parentfff2591c2a95f3a039f5603c9b9af479c930375a (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