stack bloat after stackprotector changes
Eric Sandeen
sandeen at sandeen.net
Mon Oct 5 16:01:36 CDT 2009
It seems that after:
commit 5d707e9c8ef2a3596ed5c975c6ff05cec890c2b4
Author: Tejun Heo <tj at kernel.org>
Date: Mon Feb 9 22:17:39 2009 +0900
stackprotector: update make rules
xfs stack usage jumped up a fair bit;
before:
376 xfs_bmapi
328 xfs_bulkstat
296 _xfs_trans_commit
264 xfs_iomap_write_delay
248 xlog_do_recovery_pass
248 xfs_symlink
248 xfs_file_ioctl
232 xfs_bunmapi
224 xfs_trans_unreserve_and_mod_sb
216 xfs_file_compat_ioctl
216 xfs_cluster_write
216 xfs_bmap_del_extent
200 xfs_probe_cluster
200 xfs_page_state_convert
200 xfs_iomap_write_direct
200 xfs_getbmap
...
after:
408 xfs_bmapi
344 xfs_bulkstat
312 _xfs_trans_commit
312 xfs_file_ioctl
296 xfs_file_compat_ioctl
280 xfs_iomap_write_delay
264 xlog_do_recovery_pass
264 xfs_symlink
264 xfs_bunmapi
248 xfs_bmap_del_extent
248 xfs_bmap_add_extent_delay_real
240 xfs_trans_unreserve_and_mod_sb
232 xfs_iomap_write_direct
232 xfs_cluster_write
216 xfs_probe_cluster
216 xfs_bmap_extents_to_btree
...
Not a lot in each case but could be significant as it accumulates.
I'm not familiar w/ the gcc stack protector feature; would this be an
expected result?
Thanks,
-Eric
More information about the xfs
mailing list