linux-ext4 - Re: [PATCH 1/2] ext2: speed up file creates by optimizing rec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D002B91.7020409@redhat.com>
Date:	Wed, 08 Dec 2010 20:06:25 -0500
From:	Ric Wheeler <rwheeler@...hat.com>
To:	Andreas Dilger <adilger.kernel@...ger.ca>
CC:	Eric Sandeen <sandeen@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	ext4 development <linux-ext4@...r.kernel.org>,
	Jan Kara <jack@...e.cz>
Subject: Re: [PATCH 1/2] ext2: speed up file creates by optimizing rec_len
 functions

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

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