XFS binary code size
I'm curious about the footprint of the XFS binary code, specifically for 32 bit systems, but knowing the 64 bit case would be educational as well for comparison. I don't use kernel modules or I'd already have a rough answer. My last build was 2.6.38.6 but I'm sure the size hasn't changed much in more recent kernels. My XFS build options were:
$ grep -i xfs .config CONFIG_XFS_FS=y # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_POSIX_ACL is not set # CONFIG_XFS_RT is not set
My resulting kernel image is:
$ la /boot/vmlinuz-2.6.38.6 -rw-r--r-- 1 root root 1.6M May 17 23:55 vmlinuz-2.6.38.6
How much of that 1.6MB is XFS? Also, what is the size of the hot path code that we want to stay in L1 during heavy IO?
Signature · 6 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 13 lines · Stan Hoeppner
I'm curious about the footprint of the XFS binary code, specifically for 32 bit systems, but knowing the 64 bit case would be educational as well for comparison. I don't use kernel modules or I'd already have a rough answer. My last build was 2.6.38.6 but I'm sure the size hasn't changed much in more recent kernels. My XFS build options were:
$ grep -i xfs .config CONFIG_XFS_FS=y # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_POSIX_ACL is not set # CONFIG_XFS_RT is not set
Quoted 5 lines
My resulting kernel image is:
$ la /boot/vmlinuz-2.6.38.6 -rw-r--r-- 1 root root 1.6M May 17 23:55 vmlinuz-2.6.38.6How much of that 1.6MB is XFS?
That's the compressed image that is 1.6MB, so the uncompressed kernel will be quite a bit bigger than that. As it is, the XFs binary size can be found from your source tree via:
$ size fs/xfs/xfs.ko text data bss dec hex filename 468288 59632 1400 529320 813a8 fs/xfs/xfs.ko $
So for my current kernel build on x86-64 with these options:
CONFIG_XFS_FS=yCONFIG_XFS_QUOTA=yCONFIG_XFS_POSIX_ACL=yCONFIG_XFS_RT=y
# CONFIG_XFS_DEBUG is not set
the XFS binary footprint is around 520kB. Yours will be smaller given you don't have RT, ACL and quota configured, but it will still probably be the largest single code block in your kernel...
Quoted 2 lines
Also, what is the size of the hot
path code that we want to stay in L1 during heavy IO?
Simple answer: it will stay in the L2 cache if we are lucky and userspace doesn't trash the L2 cache between syscalls.
More complex answer: run perf w/ sampling on L1/L2 cache misses and have a look for yourself.
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs