[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180524120237.25y5dqpuvdufwiam@quack2.suse.cz>
Date: Thu, 24 May 2018 14:02:37 +0200
From: Jan Kara <jack@...e.cz>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Hugh Dickins <hughd@...gle.com>, Jan Kara <jack@...e.cz>,
linux-kernel <linux-kernel@...r.kernel.org>,
stable <stable@...r.kernel.org>,
Mel Gorman <mgorman@...hsingularity.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Mel Gorman <mgorman@...e.de>
Subject: Re: [PATCH 4.4 50/92] mm: filemap: avoid unnecessary calls to
lock_page when waiting for IO to complete during a read
On Thu 24-05-18 13:28:41, Greg KH wrote:
> On Thu, May 24, 2018 at 04:17:12AM -0700, Hugh Dickins wrote:
> > Thu, May 24, 2018 at 4:06 AM Greg Kroah-Hartman
> > <gregkh@...uxfoundation.org>
> > wrote:
> >
> > > On Thu, May 24, 2018 at 12:50:11PM +0200, Jan Kara wrote:
> > > > On Thu 24-05-18 11:38:27, Greg Kroah-Hartman wrote:
> > > > > 4.4-stable review patch. If anyone has any objections, please let me
> > know.
> > > >
> > > > Just one objection: Why does stable care about this (and the previous
> > > > patch)? I've checked the stable queue and I don't see anything that
> > would
> > > > have these patches as a prerequisite. And on their own, they are only
> > > > cleanups without substantial gains.
> >
> > > There's a small gain here:
> >
> > > > > paralleldd
> > > > > 4.4.0 4.4.0
> > > > > vanilla avoidlock
> > > > > Amean Elapsd-1 5.28 ( 0.00%) 5.15 ( 2.50%)
> > > > > Amean Elapsd-4 5.29 ( 0.00%) 5.17 ( 2.12%)
> > > > > Amean Elapsd-7 5.28 ( 0.00%) 5.18 ( 1.78%)
> > > > > Amean Elapsd-12 5.20 ( 0.00%) 5.33 ( -2.50%)
> > > > > Amean Elapsd-21 5.14 ( 0.00%) 5.21 ( -1.41%)
> > > > > Amean Elapsd-30 5.30 ( 0.00%) 5.12 ( 3.38%)
> > > > > Amean Elapsd-48 5.78 ( 0.00%) 5.42 ( 6.21%)
> > > > > Amean Elapsd-79 6.78 ( 0.00%) 6.62 ( 2.46%)
> > > > > Amean Elapsd-110 9.09 ( 0.00%) 8.99 ( 1.15%)
> > > > > Amean Elapsd-128 10.60 ( 0.00%) 10.43 ( 1.66%)
> > > > >
> > > > > The impact is small but intuitively, it makes sense to avoid
> > unnecessary
> > > > > calls to lock_page.
> >
> > > Yes, it's small, but it's marked in the SLES kernel as "needs to be
> > > merged into stable", so obviously it matters to someone :)
> >
> > Hmm. I had the same reaction to these two as Jan, but assumed that they
> > made applying later patches easier, and didn't take the trouble he did to
> > find that's not so.
> >
> > I've no wish to be disputatious, but it does seem that the definition of
> > "stable" has changed, and not necessarily for the better, if it's now a
> > home for small gains: I thought we left those to upstream.
>
> This is in the SLES kernel for a reason, and again, it's in the section
> that says "this should be pushed to stable". So if it's good enough for
> the SLES kernel, why isn't it good enough for all users of this kernel
> tree?
Heh, fair enough. I guess Mel in the end didn't find patches worthy enough
to be pushed to stable tree. But at least now I know they are well tested
with 4.4 base so they should do no harm in the stable tree so my stance is
closer to neutral.
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists