From: CAI Qian <caiqian@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: possible fsync02() xfs slowness regression on power7
Date: Mon, 4 Mar 2013 01:14:02 -0500 (EST) [thread overview]
Message-ID: <1735762055.8552410.1362377642444.JavaMail.root@redhat.com> (raw)
In-Reply-To: <20130304055502.GP23616@dastard>
----- 原始邮件 -----
> 发件人: "Dave Chinner" <david@fromorbit.com>
> 收件人: "CAI Qian" <caiqian@redhat.com>
> 抄送: xfs@oss.sgi.com
> 发送时间: 星期一, 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@fromorbit.com
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2013-03-04 6:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <130819766.6999797.1362043338279.JavaMail.root@redhat.com>
2013-02-28 9:28 ` possible fsync02() xfs slowness regression on power7 CAI Qian
2013-02-28 11:54 ` Dave Chinner
2013-03-01 9:20 ` CAI Qian
2013-03-04 4:23 ` CAI Qian
2013-03-04 5:55 ` Dave Chinner
2013-03-04 6:14 ` CAI Qian [this message]
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=1735762055.8552410.1362377642444.JavaMail.root@redhat.com \
--to=caiqian@redhat.com \
--cc=david@fromorbit.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