From: Dave Chinner <david@fromorbit.com>
To: Yann Dupont <Yann.Dupont@univ-nantes.fr>
Cc: stan@hardwarefreak.com, xfs@oss.sgi.com
Subject: Re: Bad performance with XFS + 2.6.38 / 2.6.39
Date: Tue, 3 Jan 2012 07:35:43 +1100 [thread overview]
Message-ID: <20120102203543.GP23662@dastard> (raw)
In-Reply-To: <4F0181A2.5010505@univ-nantes.fr>
On Mon, Jan 02, 2012 at 11:06:26AM +0100, Yann Dupont wrote:
> Le 22/12/2011 12:02, Yann Dupont a écrit :
> >Le 22/12/2011 10:23, Yann Dupont a écrit :
> >>
> >>>Can you run a block trace on both kernels (for say five minutes)
> >>>when the load differential is showing up and provide that to us so
> >>>we can see how the IO patterns are differing?
> >
> >
> >here we go.
> >
>
> Hello, happy new year everybody ,
>
> Did someone had time to examine the 2 blktrace ? (and, by chance,
> can see the root cause of the increased load ?)
I've had a bit of a look, but most peopl ehave been on holidays.
As it is, I can't see any material difference between the traces.
both reads and writes are taking the same amount of time to service,
so I don't think there's any problem here.
I do recall that some years ago that we changed one of the ways we
slept in XFS which meant those blocked IOs contributed to load
average (as tehy are supposed to). That meant that more IO
contributed to the load average (it might have been read related),
so load averages were then higher for exactly the same workloads.
Indeed:
load average: 0.64, 0.15, 0.09
(start 40 concurrent directory traversals w/ unlinks)
(wait a bit)
load average: 39.96, 23.75, 10.06
Yup, that is spot on - 40 processes doing blocking IO.....
So absent any measurable performance problem, I don't think the
change in load average is something to be concerned about.
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:[~2012-01-02 20:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-11 12:45 Bad performance with XFS + 2.6.38 / 2.6.39 Xupeng Yun
2011-12-11 23:39 ` Dave Chinner
2011-12-12 0:40 ` Xupeng Yun
2011-12-12 1:00 ` Dave Chinner
2011-12-12 2:00 ` Xupeng Yun
2011-12-12 13:57 ` Christoph Hellwig
2011-12-21 9:08 ` Yann Dupont
2011-12-21 15:10 ` Stan Hoeppner
2011-12-21 17:56 ` Yann Dupont
2011-12-21 22:26 ` Dave Chinner
2011-12-22 9:23 ` Yann Dupont
2011-12-22 11:02 ` Yann Dupont
2012-01-02 10:06 ` Yann Dupont
2012-01-02 16:08 ` Peter Grandi
2012-01-02 18:02 ` Peter Grandi
2012-01-04 10:54 ` Yann Dupont
2012-01-02 20:35 ` Dave Chinner [this message]
2012-01-03 8:20 ` Yann Dupont
2012-01-04 12:33 ` Christoph Hellwig
2012-01-04 13:06 ` Yann Dupont
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=20120102203543.GP23662@dastard \
--to=david@fromorbit.com \
--cc=Yann.Dupont@univ-nantes.fr \
--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 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.