ext4 stack usage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Just FYI; there are some fairly large stack users in ext4dev.  On my
x86_64 box with gcc 4.1.1, and the git patch series applied:

0x00019ac5 ext4_mb_new_blocks [ext4dev]:                424
0x0001c221 ext4_mb_free_blocks [ext4dev]:               408
0x00011390 ext4_group_add [ext4dev]:                    392
0x000050cb ext4_get_blocks_handle [ext4dev]:            328
0x0001853f ext4_mb_discard_preallocations [ext4dev]:    328
0x0000a3a2 ext4_find_entry [ext4dev]:                   312
0x0000b4de ext4_get_parent [ext4dev]:                   264
0x00013fb3 ext4_ext_get_blocks [ext4dev]:               264
0x00014969 ext4_fallocate [ext4dev]:                    264
0x0001b20a ext4_mb_seq_groups_show [ext4dev]:           264
0x00006543 ext4_truncate [ext4dev]:                     232
0x00009b3d ext4_add_entry [ext4dev]:                    216
0x0000d575 ext4_error [ext4dev]:                        216
0x0000e8f5 ext4_fill_super [ext4dev]:                   216
0x00017127 ext4_mb_release_inode_pa [ext4dev]:          216
0x000172cb ext4_mb_init_cache [ext4dev]:                216
0x0001dcad ext4_xattr_set_handle [ext4dev]:             216
0x0000d145 ext4_warning [ext4dev]:                      208
0x0000d794 ext4_abort [ext4dev]:                        208
0x000022f6 ext4_readdir [ext4dev]:                      200
0x00003292 ext4_new_inode [ext4dev]:                    200
0x0001e601 ext4_expand_extra_isize_ea [ext4dev]:        184
0x0000e07d ext4_quota_on [ext4dev]:                     168
0x00014dca ext4_ext_truncate [ext4dev]:                 168
0x00018f6f ext4_mb_write_prealloc_table [ext4dev]:      168
0x0001935a ext4_mb_seq_history_show [ext4dev]:          160
0x00005953 ext4_getblk [ext4dev]:                       152
0x00009283 do_split [ext4dev]:                          152
0x0000bf3b ext4_rename [ext4dev]:                       152
0x000132b9 ext4_ext_insert_extent [ext4dev]:            152
0x000011c9 ext4_new_blocks_old [ext4dev]:               136
0x0000831e ext4_ioctl [ext4dev]:                        136
0x00010cc9 add_new_gdb [ext4dev]:                       136
0x0001b565 ext4_mb_init [ext4dev]:                      136
0x0000ad20 ext4_htree_fill_tree [ext4dev]:              120
0x0000e225 ext4_remount [ext4dev]:                      120
0x00015c5e ext4_ext_migrate [ext4dev]:                  120
0x000008b3 ext4_try_to_allocate_with_rsv [ext4dev]:     104
0x00001e14 ext4_new_blocks [ext4dev]:                   104
0x0000b920 ext4_orphan_del [ext4dev]:                   104
0x0000c90a parse_options [ext4dev]:                     104
0x0001bf3f ext4_mb_discard_inode_preallocations [ext4dev]:104

with the push for 4k stacks, some of these might start to be an issue.

struct ext4_allocation_context might be one big hitter, at 168 bytes
when placed on the stack.

(for comparison, a few of xfs's top stack users are:)

0x0001a1b4 xfs_bmapi [xfs]:                             360
0x00045a73 _xfs_trans_commit [xfs]:                     312
0x000384d6 xfs_bulkstat [xfs]:                          296
0x0004d0b8 xfs_symlink [xfs]:                           296
0x0003798f xfs_iomap_write_delay [xfs]:                 280
0x00056254 xfs_cleanup_inode [xfs]:                     264
<big snip - xfs has many more >100byte functions than ext4>

of course callchain details matter, too, but this is worth keeping an
eye on.

-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux