From: Vivek Goyal <vgoyal@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Heinz Diehl <htd@fancy-poultry.org>,
linux-kernel@vger.kernel.org, jaxboe@fusionio.com,
nauman@google.com, dpshah@google.com, guijianfeng@cn.fujitsu.com,
jmoyer@redhat.com, czoccolo@gmail.com, "Ted Ts'o" <tytso@mit.edu>
Subject: Re: cfq fsync patch testing results (Was: Re: [RFC PATCH] cfq-iosched: IOPS mode for group scheduling and new group_idle tunable)
Date: Thu, 29 Jul 2010 10:56:32 -0400 [thread overview]
Message-ID: <20100729145632.GC25863@redhat.com> (raw)
In-Reply-To: <20100729043443.GB21736@redhat.com>
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.
>
> Ext3 results
> ============
> ext3 (2.6.35-rc6) ext3 (35-rc6-fsync)
> ----------------- -------------------
> fsync time: 3.4173 fsync time: 0.0171
> fsync time: 0.8831 fsync time: 0.0951
> fsync time: 0.6985 fsync time: 0.0848
> fsync time: 8.9449 fsync time: 0.1206
> fsync time: 4.3075 fsync time: 0.4150
> fsync time: 6.0146 fsync time: 0.0856
> fsync time: 9.7134 fsync time: 0.1151
> fsync time: 9.2247 fsync time: 0.1083
> fsync time: 6.5061 fsync time: 0.1218
> fsync time: 6.1862 fsync time: 4.1666
> fsync time: 6.1136 fsync time: 0.1075
> fsync time: 3.3593 fsync time: 0.3442
> fsync time: 4.3309 fsync time: 0.1062
> fsync time: 2.3596 fsync time: 2.8502
> fsync time: 0.0151 fsync time: 0.0433
> fsync time: 0.0180 fsync time: 4.0526
> fsync time: 0.3685 fsync time: 0.1819
> fsync time: 2.7396 fsync time: 0.1479
> fsync time: 3.1537 fsync time: 0.1480
> fsync time: 2.4474 fsync time: 0.1715
> fsync time: 2.7085 fsync time: 0.0079
> fsync time: 3.1629 fsync time: 0.0181
> fsync time: 2.9186 fsync time: 0.0134
>
> XFS results
> ==========
> XFS (2.6.35-rc6) XFS (with fsync patch)
> fsync time: 5.0746 fsync time: 1.8025
> fsync time: 3.0057 fsync time: 2.3392
> fsync time: 3.0960 fsync time: 2.2810
> fsync time: 2.8392 fsync time: 2.2894
> fsync time: 2.4901 fsync time: 2.3059
> fsync time: 2.3151 fsync time: 2.3061
> fsync time: 2.3066 fsync time: 2.9825
> fsync time: 0.6608 fsync time: 2.3144
> fsync time: 0.0595 fsync time: 2.2894
> fsync time: 2.0977 fsync time: 0.0508
> fsync time: 2.3236 fsync time: 2.3396
> fsync time: 2.3229 fsync time: 2.3310
> fsync time: 2.3065 fsync time: 2.3061
> fsync time: 2.3234 fsync time: 2.3060
> fsync time: 2.3150 fsync time: 2.3561
> fsync time: 2.3149 fsync time: 2.3313
> fsync time: 2.3234 fsync time: 2.0221
> fsync time: 2.3066 fsync time: 2.2891
> fsync time: 2.3232 fsync time: 2.3144
> fsync time: 2.3317 fsync time: 2.3144
> fsync time: 2.3321 fsync time: 2.2894
> fsync time: 2.3232 fsync time: 2.3228
> fsync time: 0.0514 fsync time: 2.3144
> fsync time: 2.2480 fsync time: 0.0506
>
> Ext4
> ====
> ext4 (vanilla) ext4 (patched)
> fsync time: 3.4080 fsync time: 2.9109
> fsync time: 17.8330 fsync time: 25.0503
> fsync time: 0.0922 fsync time: 2.5495
> fsync time: 0.0710 fsync time: 0.0943
> fsync time: 19.7977 fsync time: 0.0770
> fsync time: 20.6592 fsync time: 16.3287
> fsync time: 0.1020 fsync time: 24.4983
> fsync time: 0.0689 fsync time: 0.1006
> fsync time: 19.9981 fsync time: 0.0783
> fsync time: 20.6605 fsync time: 19.1181
> fsync time: 0.0930 fsync time: 22.0860
> fsync time: 0.0776 fsync time: 0.0909
>
>
> Notes:
> ======
> - Above results are with and without corrado's fsync issue patch. We
> happen to be discussing it in a different thread though, hence
> specifying it specifically.
>
> - I am running linus torture test and also running ted so's fsync-tester
> to monitor fsync latencies.
>
> - Looks like ext3 fsync times have improved.
> - XFS fsync times have remained unchanged.
> - ext4 fsync times seems to have gone up a bit.
>
> I used default mount options. So I am assuming high fsync times of ext4
> comes from the fact that barriers much be enabled by default. Will do
> some blktracing on ext4 case tomorrow, otherwise I think this patch
> looks good.
For the sake of completeness, I also ran same tests on ext3 with barrier
enabled.
ext3 (barrier=1) ext3 (barrier=1)
fsync time: 2.7601 fsync time: 1.5323
fsync time: 2.2352 fsync time: 1.5254
fsync time: 2.1689 fsync time: 1.4228
fsync time: 2.1666 fsync time: 1.8404
fsync time: 2.3017 fsync time: 5.6249
fsync time: 2.2256 fsync time: 1.6099
fsync time: 2.1588 fsync time: 1.5318
fsync time: 5.1648 fsync time: 2.0092
fsync time: 5.8390 fsync time: 1.9966
fsync time: 0.2109 fsync time: 2.0055
fsync time: 0.0906 fsync time: 2.0054
fsync time: 3.6327 fsync time: 0.1778
fsync time: 3.0161 fsync time: 0.0827
fsync time: 2.3194 fsync time: 2.3796
fsync time: 2.0581 fsync time: 1.5960
fsync time: 2.2850 fsync time: 1.5074
fsync time: 2.2002 fsync time: 1.8653
fsync time: 2.1932 fsync time: 1.8910
fsync time: 2.1753 fsync time: 1.9091
fsync time: 2.1669 fsync time: 1.8322
fsync time: 2.1671 fsync time: 1.8744
fsync time: 1.9552 fsync time: 1.8254
fsync time: 3.9870 fsync time: 1.8662
fsync time: 2.5140 fsync time: 1.8587
fsync time: 0.0867 fsync time: 1.7981
It is hard to say whether things improved or not with patch. I guess
slight improvement is there.
What is interesting though that this fsync-tester test case works well
with ext3 and xfs but with ext4 there seems to be large spikes in
fsync times.
[CCing Ted Tso]
Thanks
Vivek
next prev parent reply other threads:[~2010-07-29 14:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-22 21:29 [RFC PATCH] cfq-iosched: IOPS mode for group scheduling and new group_idle tunable Vivek Goyal
2010-07-22 21:29 ` [PATCH 1/5] cfq-iosched: Do not idle on service tree if slice_idle=0 Vivek Goyal
2010-07-22 21:29 ` [PATCH 2/5] cfq-iosched: Implment IOPS mode for group scheduling Vivek Goyal
2010-07-27 5:47 ` Gui Jianfeng
2010-07-27 13:09 ` Vivek Goyal
2010-07-22 21:29 ` [PATCH 3/5] cfq-iosched: Implement a tunable group_idle Vivek Goyal
2010-07-22 21:29 ` [PATCH 4/5] cfq-iosched: Print number of sectors dispatched per cfqq slice Vivek Goyal
2010-07-22 21:29 ` [PATCH 5/5] cfq-iosched: Documentation update Vivek Goyal
2010-07-22 21:36 ` Randy Dunlap
2010-07-23 20:22 ` Vivek Goyal
2010-07-23 14:03 ` [RFC PATCH] cfq-iosched: IOPS mode for group scheduling and new group_idle tunable Heinz Diehl
2010-07-23 14:13 ` Vivek Goyal
2010-07-23 14:56 ` Heinz Diehl
2010-07-23 18:37 ` Vivek Goyal
2010-07-24 8:06 ` Heinz Diehl
2010-07-26 13:43 ` Vivek Goyal
2010-07-26 13:48 ` Christoph Hellwig
2010-07-26 13:54 ` Vivek Goyal
2010-07-26 16:15 ` Heinz Diehl
2010-07-26 14:13 ` Christoph Hellwig
2010-07-27 7:48 ` Heinz Diehl
2010-07-28 20:22 ` Vivek Goyal
2010-07-28 23:57 ` Christoph Hellwig
2010-07-29 4:34 ` cfq fsync patch testing results (Was: Re: [RFC PATCH] cfq-iosched: IOPS mode for group scheduling and new group_idle tunable) Vivek Goyal
2010-07-29 14:56 ` Vivek Goyal [this message]
2010-07-29 19:39 ` Jeff Moyer
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=20100729145632.GC25863@redhat.com \
--to=vgoyal@redhat.com \
--cc=czoccolo@gmail.com \
--cc=dpshah@google.com \
--cc=guijianfeng@cn.fujitsu.com \
--cc=hch@infradead.org \
--cc=htd@fancy-poultry.org \
--cc=jaxboe@fusionio.com \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nauman@google.com \
--cc=tytso@mit.edu \
/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.