linux-ext4 - Re: compilebench numbers for ext4

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]

Date:	Mon, 22 Oct 2007 20:54:31 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	cmm@...ibm.com
Cc:	linux-ext4@...r.kernel.org
Subject: Re: compilebench numbers for ext4

On Mon, 22 Oct 2007 17:12:58 -0700
Mingming Cao <cmm@...ibm.com> wrote:

> On Mon, 2007-10-22 at 19:31 -0400, Chris Mason wrote:
> > Hello everyone,
> > 
> > I recently posted some performance numbers for Btrfs with different
> > blocksizes, and to help establish a baseline I did comparisons with
> > Ext3.
> > 
> 
> Thanks for doing this, Chris!
> 
> > The graphs, numbers and a basic description of compilebench are
> > here:
> > 
> > http://oss.oracle.com/~mason/blocksizes/
> > 
> > Ext3 easily wins the read phase, but scores poorly while creating
> > files and deleting them.  Since ext3 is winning the read phase, we
> > can assume the file layout is fairly good.  I think most of the
> > problems during the write phase are caused by pdflush doing
> > metadata writeback.  The file data and metadata are written
> > separately, and so we end up seeking between things that are
> > actually close together.
> > 
> > Andreas asked me to give ext4 a try, so I grabbed the patch queue
> > from Friday along with the latest Linus kernel.  The FS was created
> > with:
> > 
> > mkfs.ext3 -I 256 /dev/xxxx
> > mount -o delalloc,mballoc,data=ordered -t ext4dev /dev/xxxx
> > 
> > I did expect delayed allocation to help the write phases of
> > compilebench, especially the parts where it writes out .o files in
> > random order (basically writing medium sized files all over the
> > directory tree).
> 
> Unfortunately delayed allocation support for ordered mode is not there
> yet. 

Sorry, I meant to write data=writeback, not sure how my fingers typed
ordered instead.

> 
> >   But, every phase except reads showed huge
> > improvements.
> > 
> > http://oss.oracle.com/~mason/compilebench/ext4/ext-create-compare.png
> > http://oss.oracle.com/~mason/compilebench/ext4/ext-compile-compare.png
> > http://oss.oracle.com/~mason/compilebench/ext4/ext-read-compare.png
> > http://oss.oracle.com/~mason/compilebench/ext4/ext-rm-compare.png
> > 
> > To match the ext4 numbers with Btrfs, I'd probably have to turn off
> > data checksumming...
> > 
> > But oddly enough I saw very bad ext4 read throughput even when
> > reading a single kernel tree (outside of compilebench).  The time
> > to read the tree was almost 2x ext3.  Have others seen similar
> > problems?
> > 
> thanks for point this out, will run compilebench. 
> 
> Trying to understand the Disk IO graph
> http://oss.oracle.com/~mason/compilebench/ext4/ext-read-compare.png
> it looks like ext3 the blocks are spread over the disk, while ext4 is
> more around the same place, is this right?

It does look like that, but the ext4 movie shows the middle line a
little differently than the graph.  The middle ext4 line is actually
comprised of a lot of seeks.

For comparison, here's the ext3 movie:

http://oss.oracle.com/~mason/compilebench/ext4/ext3-read.mpg

Even though the ext3 data looks more spread out, there are more
throughput peaks, and fewer seeks overall in ext3.

-chris


-
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