linux-kernel - Re: cfq fsync patch testing results (Was: Re: [RFC PATCH] cfq-iosched: IOPS mode for group scheduling and new group

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] [day] [month] [year] [list]

Date:	Thu, 29 Jul 2010 15:39:37 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Heinz Diehl <htd@...cy-poultry.org>,
	linux-kernel@...r.kernel.org, jaxboe@...ionio.com,
	nauman@...gle.com, dpshah@...gle.com, guijianfeng@...fujitsu.com,
	czoccolo@...il.com, "Ted Ts'o" <tytso@....edu>
Subject: Re: cfq fsync patch testing results (Was: Re: [RFC PATCH] cfq-iosched: IOPS mode for group scheduling and new group_idle tunable)

Vivek Goyal <vgoyal@...hat.com> writes:

> On Thu, Jul 29, 2010 at 12:34:43AM -0400, Vivek Goyal wrote:
>> On Wed, Jul 28, 2010 at 07:57:16PM -0400, Christoph Hellwig wrote:
>> > On Wed, Jul 28, 2010 at 04:22:12PM -0400, Vivek Goyal wrote:
>> > > I also did "time firefox &" testing to see how long firefox takes to
>> > > launch when linus torture test is running and without patch it took
>> > > around 20 seconds and with patch it took around 17 seconds. 
>> > > 
>> > > So to me above test results suggest that this patch does not worsen
>> > > the performance. In fact it helps. (at least on ext3 file system.)
>> > > 
>> > > Not sure why are you seeing different results with XFS.
>> > 
>> > So why didn't you test it with XFS to verify his results?
>> 
>> Just got little lazy. Find the testing results with ext3, ext4 and
>> xfs below.
>> 
>> >  We all know
>> > that different filesystems have different I/O patters, and we have
>> > a history of really nasty regressions in one filesystem by good meaning
>> > changes to the I/O scheduler.
>> > 
>> > ext3 in fact is a particularly bad test case as it not only doesn't have
>> > I/O barriers enabled, but also has particularly bad I/O patterns
>> > compared to modern filesystems.

A string of numbers is hard for me to parse.  In the hopes that this
will help others, here is some awk-fu that I shamelessly stole from the
internets:

awk '{total1+=$3; total2+=$6; array1[NR]=$3; array2[NR]=$6} END{for(x=1;x<=NR;x++){sumsq1+=((array1[x]-(total1/NR))**2); sumsq2+=((array2[x]-(total2/NR))**2);}print total1/NR " " sqrt(sumsq1/NR) " " total2/NR " " sqrt(sumsq2/NR)}'

>> Ext3 results
>> ============
>> ext3 (2.6.35-rc6)	ext3 (35-rc6-fsync)
>> -----------------	-------------------
avg     stddev           avg       stddev
3.8953  2.80654          0.587943  1.22399

>> 
>> XFS results
>> ==========
>> XFS (2.6.35-rc6)	XFS (with fsync patch)
2.2538 0.95565          2.11869 0.649704

>> Ext4
>> ====
>> ext4 (vanilla)		ext4 (patched)
8.57177 9.54596                 9.41524 10.4037

> ext3 (barrier=1)	ext3 (barrier=1)
2.40316 1.26992         1.82272 0.922305

It is interesting that ext4 does worse with the patch (though,
realistically, not by much).

Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/