From: Ric Wheeler <rwheeler@redhat.com>
To: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Eric Sandeen <sandeen@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
ext4 development <linux-ext4@vger.kernel.org>,
Jan Kara <jack@suse.cz>
Subject: Re: [PATCH 1/2] ext2: speed up file creates by optimizing rec_len functions
Date: Wed, 08 Dec 2010 20:06:25 -0500 [thread overview]
Message-ID: <4D002B91.7020409@redhat.com> (raw)
In-Reply-To: <F51EB2BF-8C99-4E2F-943E-E795A0F4DF7F@dilger.ca>
On 12/08/2010 04:44 PM, Andreas Dilger wrote:
> On 2010-12-08, at 14:07, Eric Sandeen wrote:
>> On 12/08/2010 01:01 PM, Andreas Dilger wrote:
>>> I think an important factor here is that this is being tested on a
>>> ramdisk, and is likely CPU bound, so any CPU reduction will directly
>>> be measured as a performance improvement. Probably oprofile is in
>>> order to see where other major CPU users are.
>> Yep, I ran oprofile.
>>
>> samples % app name symbol name
>> 1140046 41.8702 ext2.ko ext2_find_entry
>> 1052117 38.6408 ext2.ko ext2_add_link
>> 98424 3.6148 vmlinux native_safe_halt
>> 40461 1.4860 vmlinux wait_on_page_read
>> 29084 1.0682 vmlinux find_get_page
>>
>> pretty slammed on those 2 ext2 functions! I think it's pretty
>> overwhelmed by the linear search.
> Can you test ext4 with nojournal mode, but with dir_index enabled? I suspect that testing ext2 for directory performance is pointless. My personal threshold for ext2 directories was 10k files before I considered it a lost cause, and all of your tests are with 10k+ files per directory.
>
> Just another log on the fire beneath getting rid of ext2 (and eventually ext3) in favour of ext4, IMHO. I'd be surprised if there are many benchmarks that ext2 can beat ext4 in nojournal mode, if allowed to enable "reversible" format changes like dir_index, uninit_bg, etc.
>
> Cheers, Andreas
>
If we could get rid of ext2 (and eventually ext3), it would actually help reduce
the testing matrix and possibly let us invest even more in testing ext4. Having
to maintain three very similar code bases and test them all for correctness and
performance is a real pain :)
ric
next prev parent reply other threads:[~2010-12-09 1:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-07 17:47 [PATCH 0/2] ext2, ext3: speed up file create workloads Eric Sandeen
2010-12-07 17:51 ` [PATCH 1/2] ext2: speed up file creates by optimizing rec_len functions Eric Sandeen
2010-12-07 21:07 ` Andrew Morton
2010-12-07 21:22 ` Eric Sandeen
2010-12-07 21:33 ` Andrew Morton
2010-12-07 21:36 ` Eric Sandeen
2010-12-08 19:01 ` Andreas Dilger
2010-12-08 21:07 ` Eric Sandeen
2010-12-08 21:44 ` Andreas Dilger
2010-12-09 1:06 ` Ric Wheeler [this message]
2010-12-10 17:55 ` Ted Ts'o
2010-12-10 18:05 ` Ric Wheeler
2010-12-10 23:40 ` Andreas Dilger
2010-12-11 0:24 ` Eric Sandeen
2010-12-09 2:13 ` Eric Sandeen
2010-12-07 17:55 ` [PATCH 2/2] ext3: " Eric Sandeen
2011-01-06 14:47 ` [PATCH 0/2] ext2, ext3: speed up file create workloads Jan Kara
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=4D002B91.7020409@redhat.com \
--to=rwheeler@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).