I revamped the commit message for patch 1, explicitly spelling out a bunch of things and adding bpftrace output. Please read it. There was some massaging of lines in the include/linux/fs.h header files. If you don't like it I would appreciate if you adjusted it however you see fit on your own. This adjusts the state to what was suggested by Christian. Specific results: ext4 (needed mkfs.ext4 -N 24000000): before: 3.77s user 890.90s system 1939% cpu 46.118 total after: 3.24s user 397.73s system 1858% cpu 21.581 total (-53%) btrfs (s/iget5_locked/iget5_locked_rcu in fs/btrfs/inode.c): before: 3.54s user 892.30s system 1966% cpu 45.549 total after: 3.28s user 738.66s system 1955% cpu 37.932 total (-16.7%) btrfs bottlenecks itself on its own locks here. Benchmark info in the commit message to the first patch. fs rundown is as follows: - ext4 patched implicitly - xfs does not use the inode hash - bcachefs is out of the picture as Kent decided to implement his own inode hashing based on rhashtable, for now private to his fs. - btrfs handled in the patchset I have not looked at others. v4: - only provide iget5_locked_rcu - add a btrfs ack v3: - export new routines with _GPL - don't use the extern keyword - add ilookup5_rcu to follow iget5_locked scheme v2: - add argument lists to new routines - assert the inode hash lock is not held as applicable - real btrfs patch included Mateusz Guzik (2): vfs: add rcu-based find_inode variants for iget ops btrfs: use iget5_locked_rcu fs/btrfs/inode.c | 2 +- fs/inode.c | 119 ++++++++++++++++++++++++++++++++++++++------- include/linux/fs.h | 10 +++- 3 files changed, 112 insertions(+), 19 deletions(-) -- 2.43.0
