* ext4 stack usage
@ 2007-11-05 17:50 Eric Sandeen
0 siblings, 0 replies; only message in thread
From: Eric Sandeen @ 2007-11-05 17:50 UTC (permalink / raw)
To: ext4 development
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2007-11-05 17:51 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-05 17:50 ext4 stack usage Eric Sandeen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.