From: Eric Sandeen <sandeen@redhat.com>
To: paul.chavent@fnac.net
Cc: linux-ext4@vger.kernel.org
Subject: Re: What represent 646345728 bytes
Date: Mon, 01 Feb 2010 16:36:47 -0600 [thread overview]
Message-ID: <4B67577F.70207@redhat.com> (raw)
In-Reply-To: <4B67347C.3030103@redhat.com>
Eric Sandeen wrote:
> So uninit_bg doesn't seem to help. (this was on 2.6.32-ish)
>
> some oprofiling may be in order ...
Or stapping ... thanks to hints from the stap guys, using a modified version of
http://sourceware.org/systemtap/examples/profiling/fntimes.stp
I printed out function times higher than avg and correlated to writes
above average from the testcase (cleaned up manually a bit):
1265062212927230 function ext4_mb_load_buddy well over average time (42303 vs 2)
1265062212927399 function ext4_mb_regular_allocator well over average time (42476 vs 5495)
1265062212949252 function ext4_mb_mark_diskspace_used well over average time (21739 vs 196)
1265062212949306 function ext4_mb_new_blocks well over average time (64738 vs 2457)
1265062212949647 function ext4_ext_get_blocks well over average time (65211 vs 1106)
1265062212949678 function ext4_get_blocks well over average time (65357 vs 1844)
1265062212949695 function ext4_get_block well over average time (65479 vs 683)
1265062212951284 function ext4_ind_direct_IO well over average time (68891 vs 3034)
1265062212951299 function ext4_direct_IO well over average time (68908 vs 3046)
1265062212951497 function ext4_file_write well over average time (69437 vs 3590)
1265062212951534 size 134470144 time 69477310 avg 3601820
Unfortunately under ext4_mb_load_buddy is a lot of static/inlined functions
so no more detailed info yet.
But loading the buddy bitmap for a new group seems to be the big
hitter here - I'll keep digging, or maybe Aneesh, who groks mballoc
better than I do (I think) might have an idea.
But yeah, writes randomly taking 20x longer than usual sounds bad. :(
-Eric
next prev parent reply other threads:[~2010-02-01 22:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-01 17:06 What represent 646345728 bytes paul.chavent
2010-02-01 20:07 ` Eric Sandeen
2010-02-01 22:36 ` Eric Sandeen [this message]
2010-02-01 23:01 ` Andreas Dilger
-- strict thread matches above, loose matches on Subject: below --
2010-02-01 14:08 paul.chavent
2010-02-01 15:06 ` Eric Sandeen
2010-02-01 17:20 ` Aneesh Kumar K. V
2010-02-01 17:34 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B67577F.70207@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=paul.chavent@fnac.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.