From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Michael Monnerie <michael.monnerie@is.it-management.at>,
Stan Hoeppner <stan@hardwarefreak.com>,
xfs@oss.sgi.com
Subject: Re: observed significant performance improvement using "delaylog" in
Date: Sat, 14 Aug 2010 00:13:44 +1000 [thread overview]
Message-ID: <20100813141344.GE10429@dastard> (raw)
In-Reply-To: <20100813122907.GA14650@infradead.org>
On Fri, Aug 13, 2010 at 08:29:07AM -0400, Christoph Hellwig wrote:
> On Fri, Aug 13, 2010 at 12:35:44PM +0200, Michael Monnerie wrote:
> > On Freitag, 13. August 2010 Stan Hoeppner wrote:
> > > Some benchmark results maybe worth a look:
> > > http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/
> >
> > Thanks - it would have been great to see xfs with delaylog in that
> > comparison, but the graphs are very very nice.
> >
> > XFS seems performing better the more threads there are, just in "large
> > file random reads" it's the slowest - why this?
>
> Any idea who is doing these runs?
IIRC the tests are run by someone from IBM, but I cannot remember
who it is.
> Once we figure out what that large
> file random reads loads is I'm sure we could fix it soon.
>From http://btrfs.boxacle.net/:
Random Reads (raid, single-disk)
Start with 1024 files.
100 MB files on the raid system.
35 MB files on the single-disk system.
Each thread reads a fixed amount of data from a random location in one file using 4 kB reads.
5 MB reads on the raid system.
1 MB reads on the single-disk system.
So it's not a small random read workload (100GB data set), so the
files on XFS are probably more spread out over multiple AGs
and hence further apart than other filesystems. Hence a greater
average seek distance, hence it slower throughput....
> And asking
> him/her to add -o delaylog would also be good.
Yes, that would be an interesting comparison...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-08-13 14:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-12 10:46 observed significant performance improvement using "delaylog" in Khelben Blackstaff
2010-08-12 19:05 ` Michael Monnerie
2010-08-12 21:46 ` Peter Niemayer
2010-08-13 9:56 ` Stan Hoeppner
2010-08-13 10:35 ` Michael Monnerie
2010-08-13 12:29 ` Christoph Hellwig
2010-08-13 14:13 ` Dave Chinner [this message]
2010-08-13 20:42 ` Eric Sandeen
2010-08-14 11:28 ` Martin Steigerwald
2010-08-16 0:30 ` Steven Pratt
2010-08-16 1:03 ` Dave Chinner
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=20100813141344.GE10429@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=michael.monnerie@is.it-management.at \
--cc=stan@hardwarefreak.com \
--cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox