[lkml]   [2019]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] Revert "mm: don't reclaim inodes with many attached pages"
On 30 Jan 2019, at 20:34, Dave Chinner wrote:

> On Wed, Jan 30, 2019 at 12:21:07PM +0000, Chris Mason wrote:
>> On 29 Jan 2019, at 23:17, Dave Chinner wrote:
>>> From: Dave Chinner <>
>>> This reverts commit a76cf1a474d7dbcd9336b5f5afb0162baa142cf0.
>>> This change causes serious changes to page cache and inode cache
>>> behaviour and balance, resulting in major performance regressions
>>> when combining worklaods such as large file copies and kernel
>>> compiles.
>> I'm a little confused by the latest comment in the bz:
> Which says the first patch that changed the shrinker behaviour is
> the underlying cause of the regression.
>> Are these reverts sufficient?
> I think so.

Based on the latest comment:

"If I had been less strict in my testing I probably would have
discovered that the problem was present earlier than 4.19.3. Mr Gushins
commit made it more visible.
I'm going back to work after two days off, so I might not be able to
respond inside your working hours, but I'll keep checking in on this as
I get a chance."

I don't think the reverts are sufficient.

>> Roman beat me to suggesting Rik's followup. We hit a different
>> problem
>> in prod with small slabs, and have a lot of instrumentation on Rik's
>> code helping.
> I think that's just another nasty, expedient hack that doesn't solve
> the underlying problem. Solving the underlying problem does not
> require changing core reclaim algorithms and upsetting a page
> reclaim/shrinker balance that has been stable and worked well for
> just about everyone for years.

Things are definitely breaking down in non-specialized workloads, and
have been for a long time.


 \ /
  Last update: 2019-01-31 16:50    [W:0.169 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site