summaryrefslogtreecommitdiff
path: root/fs/ext4/ext4.h
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@redhat.com>2009-07-05 22:17:31 -0400
committerTheodore Ts'o <tytso@mit.edu>2009-07-05 22:17:31 -0400
commit089ceecc1ea4a69ed8bcc5c7c7b96ce487e26b33 (patch)
tree141821f26ff0d6e201f43b0c18b26075cea376a4 /fs/ext4/ext4.h
parentf4a01017d678fe4baecf480e79d7c4f4b7ebc772 (diff)
downloadlwn-089ceecc1ea4a69ed8bcc5c7c7b96ce487e26b33.tar.gz
lwn-089ceecc1ea4a69ed8bcc5c7c7b96ce487e26b33.zip
ext4: mark several more functions in mballoc.c as noinline
Ted noticed a stack-deep callchain through writepages->ext4_mb_regular_allocator->ext4_mb_init_cache->submit_bh ... With all the static functions in mballoc.c, gcc helpfully inlines for us, and we get something like this: ext4_mb_regular_allocator (232 bytes stack) ext4_mb_init_cache (232 bytes stack) submit_bh (starts 464 deeper) the 2 ext4 functions here get several others inlined; by telling gcc not to inline them, we can save stack space for when we head off into submit_bh land and associated block layer callchains. The following noinlined functions are only called once, so this won't impact any other callchains: ext4_mb_regular_allocator (104) (was 232) ext4_mb_find_by_goal (56) (noinlined) ext4_mb_init_group (24) (noinlined) ext4_mb_init_cache (136) (was 232) ext4_mb_generate_buddy (88) (noinlined) ext4_mb_generate_from_pa (40) (noinlined) submit_bh ext4_mb_simple_scan_group (24) (noinlined) ext4_mb_scan_aligned (56) (noinlined) ext4_mb_complex_scan_group (40) (noinlined) ext4_mb_try_best_found (24) (noinlined) now when we head off into submit_bh() we're only 264 bytes deeper in stack than when we entered ext4_mb_regular_allocator() (vs. 464 bytes before). Every 200 bytes helps. :) Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Diffstat (limited to 'fs/ext4/ext4.h')
0 files changed, 0 insertions, 0 deletions