xfs: type verification is expensive

xfs: type verification is expensive

Source kernel commit: ec08c14ba28ce073b3f63c8edbee0f3c38e1b6a1

From a concurrent rm -rf workload:

41.04%  [kernel]  [k] xfs_dir3_leaf_check_int
9.85%  [kernel]  [k] __xfs_dir3_data_check
5.60%  [kernel]  [k] xfs_verify_ino
5.32%  [kernel]  [k] xfs_agino_range
4.21%  [kernel]  [k] memcpy
3.06%  [kernel]  [k] xfs_errortag_test
2.57%  [kernel]  [k] xfs_dir_ino_validate
1.66%  [kernel]  [k] xfs_dir2_data_get_ftype
1.17%  [kernel]  [k] do_raw_spin_lock
1.11%  [kernel]  [k] xfs_verify_dir_ino
0.84%  [kernel]  [k] __raw_callee_save___pv_queued_spin_unlock
0.83%  [kernel]  [k] xfs_buf_find
0.64%  [kernel]  [k] xfs_log_commit_cil

THere's an awful lot of overhead in just range checking inode
numbers in that, but each inode number check is not a lot of code.
The total is a bit over 14.5% of the CPU time is spent validating
inode numbers.

The problem is that they deeply nested global scope functions so the
overhead here is all in function call marshalling.

text    data     bss     dec     hex filename
2077       0       0    2077     81d fs/xfs/libxfs/xfs_types.o.orig
2197       0       0    2197     895 fs/xfs/libxfs/xfs_types.o

There's a small increase in binary size by inlining all the local
nested calls in the verifier functions, but the same workload now
profiles as:

40.69%  [kernel]  [k] xfs_dir3_leaf_check_int
10.52%  [kernel]  [k] __xfs_dir3_data_check
6.68%  [kernel]  [k] xfs_verify_dir_ino
4.22%  [kernel]  [k] xfs_errortag_test
4.15%  [kernel]  [k] memcpy
3.53%  [kernel]  [k] xfs_dir_ino_validate
1.87%  [kernel]  [k] xfs_dir2_data_get_ftype
1.37%  [kernel]  [k] do_raw_spin_lock
0.98%  [kernel]  [k] xfs_buf_find
0.94%  [kernel]  [k] __raw_callee_save___pv_queued_spin_unlock
0.73%  [kernel]  [k] xfs_log_commit_cil

Now we only spend just over 10% of the time validing inode numbers
for the same workload. Hence a few "inline" keyworks is good enough
to reduce the validation overhead by 30%...

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>