Filipe Manana f40ca9cb58 btrfs: locking: inline btrfs_tree_lock() and btrfs_tree_read_lock()
The functions btrfs_tree_lock() and btrfs_tree_read_lock() are very
trivial so that can be made inline and avoid call overhead, as they
are very often called inside critical sections (when searching a btree
for example, attempting to lock a child node/leaf while holding a lock
on the parent).

So make them static inline, which even reduces the size of the btrfs
module a little bit.

Before this change:

   $ size fs/btrfs/btrfs.ko
      text	   data	    bss	    dec	    hex	filename
   1718786	 156276	  16920	1891982	 1cde8e	fs/btrfs/btrfs.ko

After this change:

   $ size fs/btrfs/btrfs.ko
      text	   data	    bss	    dec	    hex	filename
   1718650	 156260	  16920	1891830	 1cddf6	fs/btrfs/btrfs.ko

Running fs_mark also showed a tiny improvement with this script:

   $ cat test.sh
   #!/bin/bash

   DEV=/dev/nullb0
   MNT=/mnt/nullb0
   FILES=100000
   THREADS=$(nproc --all)

   echo "performance" | \
       tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

   umount $DEV &> /dev/null
   mkfs.btrfs -f $DEV
   mount $DEV $MNT

   OPTS="-S 0 -L 5 -n $FILES -s 0 -t $THREADS -k"
   for ((i = 1; i <= $THREADS; i++)); do
        OPTS="$OPTS -d $MNT/d$i"
   done

   fs_mark $OPTS

   umount $MNT

Before this change:

   FSUse%        Count         Size    Files/sec     App Overhead
       10      1200000            0     180894.0         10705410
       16      2400000            0     228211.4         10765738
       23      3600000            0     215969.6         11011072
       30      4800000            0     199077.1         11145587
       46      6000000            0     176624.1         11658470

After this change:

   FSUse%        Count         Size    Files/sec     App Overhead
       10      1200000            0     185312.3         10708377
       16      2400000            0     229320.4         10858013
       23      3600000            0     217958.7         11006167
       30      4800000            0     205122.9         11112899
       46      6000000            0     178039.1         11438852

Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2024-05-07 21:31:00 +02:00
..
2024-04-22 15:34:27 +00:00
2024-01-11 20:11:35 -08:00
2024-03-27 13:17:15 +01:00
2024-03-12 13:17:36 -07:00
2024-03-18 15:39:48 -07:00
2024-03-21 09:47:12 -07:00
\n
2024-03-13 14:30:58 -07:00
2024-03-27 13:17:15 +01:00
2024-03-27 13:17:15 +01:00
2024-03-25 10:53:39 -07:00
2023-12-29 11:58:34 -08:00
2024-03-11 09:38:17 -07:00
2024-03-11 09:38:17 -07:00
2024-03-04 18:35:21 +01:00
2024-03-27 13:17:15 +01:00
2024-03-12 14:27:37 -07:00
2024-04-29 12:07:37 -07:00
2024-04-29 14:22:24 -07:00
2024-03-27 13:17:15 +01:00
2024-03-27 13:17:15 +01:00
2024-03-12 17:44:08 -07:00
2024-04-06 09:14:18 -07:00
2024-03-12 20:03:34 -07:00
2023-10-30 19:28:19 -10:00
2024-03-11 10:07:03 -07:00
2024-03-06 10:52:12 +01:00
2024-03-11 09:38:17 -07:00
2024-03-27 09:57:30 -07:00
2024-03-11 10:07:03 -07:00
2024-03-12 20:03:34 -07:00
2023-12-12 14:24:14 +01:00
2024-03-15 09:00:09 -07:00
2024-03-13 12:53:53 -07:00
2024-03-13 12:53:53 -07:00
2024-03-11 10:21:06 -07:00
2024-03-13 12:53:53 -07:00
2024-03-12 20:03:34 -07:00
2024-03-13 12:53:53 -07:00
2024-02-02 13:11:49 +01:00
2024-03-12 20:03:34 -07:00
2024-01-08 10:57:34 -08:00
2024-03-27 13:17:15 +01:00
2024-02-15 23:43:47 -05:00