[Top] [All Lists]

Re: possible fsync02() xfs slowness regression on power7

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: possible fsync02() xfs slowness regression on power7
From: CAI Qian <caiqian@xxxxxxxxxx>
Date: Mon, 4 Mar 2013 01:14:02 -0500 (EST)
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130304055502.GP23616@dastard>

----- ååéä -----
> åää: "Dave Chinner" <david@xxxxxxxxxxxxx>
> æää: "CAI Qian" <caiqian@xxxxxxxxxx>
> æé: xfs@xxxxxxxxxxx
> åéæé: ææä, 2013å 3 æ 04æ äå 1:55:02
> äé: Re: possible fsync02() xfs slowness regression on power7
> On Sun, Mar 03, 2013 at 11:23:26PM -0500, CAI Qian wrote:
> > 
> > > > And this commit in 3.9-rc1:
> > > > 
> > > > a1e16c2 xfs: limit speculative prealloc size on sparse files
> > > > should fix the problem. Please confirm these commits are the
> > > > cause
> > > > and the fix respectively....
> > Confirmed this fixed the problem. I'd like to request this to be
> > back-ported
> > to stable-3.0, stable-3.4 and stable-3.8. What do you think?
> IMO, no, it is not a backport candidate.  The patch has quite a few
> dependencies, and at least for 3.0 xfs_bmapi_read() doesn't exist
> and hence is not a trivial backport.
It is fine to skip the 3.0 then, but the other stable branches can be applied
as it iis and build fine.
> Further, it's take 2 years for this to be noticed, and you haven't
> explained why the problem exists on your power machine and not any
> others that it has been tested on. And there's been very few
> complaints about performance of such workloads over the past 2
> years, so either the workload is not important or only your power7
> machine is having problems.
Hmm, it could also be possible that it was easy to reproduce now with the
new kernel plus new user-spaces as well the new compiler. Also, those systems
started to switch to use XFS as root partitions from ext4 only recently,
so we have never noticed this in the past when running those LTP tests.
XFS could also become more popular than 2-year ago. :)
> Hence I don't see any need to back port it - it's not a critical fix
> and very few people see the problem so there's no real need to do
> the backport.  Maybe someone else has the time and resources to
> waste on backporting non-critical fixes to stable kernels, but I
> don't....
I have time so I can do the back-port for you guys to review if you
don't mind. Thanks for your time.
> Cheers,
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>