All of lore.kernel.org
 help / color / mirror / Atom feed
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
Subject: 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 00:34:43 -0400	[thread overview]
Message-ID: <20100729043443.GB21736@redhat.com> (raw)
In-Reply-To: <20100728235716.GA12945@infradead.org>

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.

Thanks
Vivek 

  reply	other threads:[~2010-07-29  4:35 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               ` Vivek Goyal [this message]
2010-07-29 14:56                 ` 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 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=20100729043443.GB21736@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 \
    /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.