From: Greg KH <gregkh@linuxfoundation.org>
To: Eduardo Valentin <eduval@amazon.com>
Cc: Willy Tarreau <w@1wt.eu>,
stable@vger.kernel.org, shli@fb.com, neilb@suse.com,
colyli@suse.de
Subject: Re: [stable v4.9.y] Backports to fix fstrim time / CPU load on raid0
Date: Fri, 22 Sep 2017 21:05:28 +0200 [thread overview]
Message-ID: <20170922190528.GA17075@kroah.com> (raw)
In-Reply-To: <20170922183859.GC11575@u40b0340c692b58f6553c.ant.amazon.com>
On Fri, Sep 22, 2017 at 11:38:59AM -0700, Eduardo Valentin wrote:
> Hello Willy,
>
> On Fri, Sep 22, 2017 at 08:11:22PM +0200, Willy Tarreau wrote:
> > On Fri, Sep 22, 2017 at 10:40:48AM -0700, Eduardo Valentin wrote:
> > > On Fri, Sep 22, 2017 at 07:31:45PM +0200, Greg KH wrote:
> > > > On Fri, Sep 22, 2017 at 10:16:06AM -0700, Eduardo Valentin wrote:
> > > > > Hello GregKH,
> > > > >
> > > > > I have been seeing several reports of performance issue with raid0 while performing fstrim on v4.9.y.
> > > > > Currently, if one performs:
> > > > >
> > > > > # fio --name fio_test_file --direct=1 --rw=randwrite --bs=4k --size=5G --numjobs=8 --group_reporting --directory=/mount/raid0
> > > > > # rm -rf /media/nvme-raid0
> > > > > # time fstrim -vvv -a
> > > > > real 3m41.102s
> > > > > user 0m0.000s
> > > > > sys 0m4.964s
> > > >
> > > > Also, is this a regression from older kernels?
> > >
> > > I personally did not try older than 4.9 kernels. but looking at git history,
> > > and the commit message of the fix, looks like this is long known issue that
> > > got fixed on v4.12.
> >
> > Or it may simply be something that couldn't be achieved without significantly
> > improving the underlying infrastructure using the patches you've spotted (and
> > possibly a few others that you didn't notice but are required for stability
> > or to avoid breaking other subsystems).
> >
> > While I use 4.9 on many of my machines, I'd rather favor maximal stability
> > over an optimization for some operations that don't appear *that* often.
> > That said if the relevant maintainers consider it safe to backport, I'll
> > certainly welcome some performance improvements on my machines, but that's
> > not what I'm primarily looking for in stable kernels.
> >
> > And if we start to backport performance improvements into LTS kernels,
> > what will encourage users to upgrade to the next LTS ?
>
> Yeah, I pondered for several days before opening up this backport
> request exactly because of your concerns above.
>
> But what made me to decide to share the backport for the community
> consideration is the way I see this. To me, this is *not only* a
> matter of performance boost, but also a real fix. Mainly because the
> systems with v4.9.y become unresponsive while performing fstrim
> because of kernel CPU consumption with the fstrim implementation in
> raid0. Meaning, depending on how this is deployed, how you use your
> fs, and how you deploy your raid, this can be a real problem on
> production systems.
>
> So, yeah, I hope you consider this not only from a performance
> perspective, but a fix for a real issue.
It might be a "fix", but given that this isn't a regression, the reason
for backporting this is pretty low. If you want faster I/O, upgrade to
a newer kernel, sounds like a good reason to me (not to mention more
features and more bugfixes as well!) :)
So I would need some big explainations by the developers involved here
as to why I should take it (which is what has caused me to take such
things in the past for other subsystems...)
thanks,
greg k-h
prev parent reply other threads:[~2017-09-22 19:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-22 17:16 [stable v4.9.y] Backports to fix fstrim time / CPU load on raid0 Eduardo Valentin
2017-09-22 17:31 ` Greg KH
2017-09-22 17:39 ` Eduardo Valentin
2017-09-22 17:31 ` Greg KH
2017-09-22 17:40 ` Eduardo Valentin
2017-09-22 18:11 ` Willy Tarreau
2017-09-22 18:38 ` Eduardo Valentin
2017-09-22 19:05 ` Greg KH [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=20170922190528.GA17075@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=colyli@suse.de \
--cc=eduval@amazon.com \
--cc=neilb@suse.com \
--cc=shli@fb.com \
--cc=stable@vger.kernel.org \
--cc=w@1wt.eu \
/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.