Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Roman Gushchin <guro@fb.com>
To:     Michal Hocko <mhocko@kernel.org>
CC:     "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Kernel Team <Kernel-team@fb.com>,
        "Rik van Riel" <riel@surriel.com>,
        Randy Dunlap <rdunlap@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "dairinin@gmail.com" <dairinin@gmail.com>
Subject: Re: [RFC PATCH] mm: don't reclaim inodes with many attached pages
Thread-Topic: [RFC PATCH] mm: don't reclaim inodes with many attached pages
Thread-Index: AQHUau+GsFRIu7vNQ0mBGnFYa9WgU6UxPgGAgAB1JQA=
Date:   Fri, 26 Oct 2018 15:56:55 +0000
Message-ID: <20181026155652.GA7647@tower.DHCP.thefacebook.com>
References: <20181023164302.20436-1-guro@fb.com>
 <20181026085735.GZ18839@dhcp22.suse.cz>
In-Reply-To: <20181026085735.GZ18839@dhcp22.suse.cz>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:200::7:4473]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;BY2PR15MB0342;20:WePtgON9dFB1Y48s484W8xRAgAvozNkr7pNWKJhpqZ9g+WrnFwyAqiR+DtntGdNja1a+ULYEqE0524lMb7StotmwFDImqmKehZbjE6SbsEfwUzQtMvnLQaHtpb4+sZ4FnW+bBcoGmBbXGcf36cuvNdtO/yDi+oMs0E/zevYIV9w=
x-ms-office365-filtering-correlation-id: b39f77dc-999c-4eb4-5adf-08d63b5ba74c
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020);SRVR:BY2PR15MB0342;
x-ms-traffictypediagnostic: BY2PR15MB0342:
x-microsoft-antispam-prvs: <BY2PR15MB0342CB83AA4537AB26DADDA8BEF00@BY2PR15MB0342.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(72170088055959);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(823302103)(93006095)(93001095)(10201501046)(3002001)(3231355)(11241501184)(944501410)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095);SRVR:BY2PR15MB0342;BCL:0;PCL:0;RULEID:;SRVR:BY2PR15MB0342;
x-forefront-prvs: 083751FCA6
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(346002)(136003)(366004)(39860400002)(396003)(376002)(199004)(189003)(76176011)(9686003)(386003)(2900100001)(54906003)(86362001)(6506007)(5250100002)(105586002)(106356001)(316002)(6512007)(11346002)(33896004)(25786009)(6436002)(446003)(39060400002)(102836004)(229853002)(6246003)(99286004)(486006)(97736004)(52116002)(476003)(53936002)(186003)(4326008)(46003)(7736002)(2906002)(14454004)(305945005)(5660300001)(478600001)(33656002)(8936002)(71190400001)(71200400001)(1076002)(6916009)(81166006)(6116002)(6486002)(81156014)(5024004)(8676002)(68736007)(256004)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR15MB0342;H:BY2PR15MB0167.namprd15.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1;
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
x-microsoft-antispam-message-info: hMXHNlv2gUw8XfxKBoVA0Jxt9RWHZxyUMJf7kttoPtpHcEiXi3mkSOZMZwtmrrn7WGYsxJBpYsqercGbXncAkQ38KTicGlrq4c1sHcdjvkE/o+GBZDZq5p6osZ3hBTMfu4idxpdp8S2pRGJd9uSKeoqwcBEpOqEtRCX69DAH8I3ncXwkZP+mHJ2Tf6VMcpdDV3w+Sa/3SV7xhc0beD0bfQOObz1Dygc+BXoYJQqeKo1WgwyiDH7BDjtPg4MbKE3kMB5US0gosgK4Ae7hLeUnwx+VaF0On4Cle5NaGFkchJNTZD7MfJESdAi9tofkQYAZl7ncfeIYo0P6FqT0QqxBTq1YVykzjLAj1zFejaKlBFw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F06829E07D1E6740BB7B73B6C40FC021@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b39f77dc-999c-4eb4-5adf-08d63b5ba74c
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2018 15:56:55.9053
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0342
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-26_08:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Oct 26, 2018 at 10:57:35AM +0200, Michal Hocko wrote:
> Spock doesn't seem to be cced here - fixed now
>=20
> On Tue 23-10-18 16:43:29, Roman Gushchin wrote:
> > Spock reported that the commit 172b06c32b94 ("mm: slowly shrink slabs
> > with a relatively small number of objects") leads to a regression on
> > his setup: periodically the majority of the pagecache is evicted
> > without an obvious reason, while before the change the amount of free
> > memory was balancing around the watermark.
> >=20
> > The reason behind is that the mentioned above change created some
> > minimal background pressure on the inode cache. The problem is that
> > if an inode is considered to be reclaimed, all belonging pagecache
> > page are stripped, no matter how many of them are there. So, if a huge
> > multi-gigabyte file is cached in the memory, and the goal is to
> > reclaim only few slab objects (unused inodes), we still can eventually
> > evict all gigabytes of the pagecache at once.
> >=20
> > The workload described by Spock has few large non-mapped files in the
> > pagecache, so it's especially noticeable.
> >=20
> > To solve the problem let's postpone the reclaim of inodes, which have
> > more than 1 attached page. Let's wait until the pagecache pages will
> > be evicted naturally by scanning the corresponding LRU lists, and only
> > then reclaim the inode structure.
>=20
> Has this actually fixed/worked around the issue?

Spock wrote this earlier to me directly. I believe I can quote it here:

"Patch applied, looks good so far. System behaves like it was with
pre-4.18.15 kernels.
Also tried to add some user-level tests to the geneic background activity, =
like
- stat'ing a bunch of files
- streamed read several large files at once on ext4 and XFS
- random reads on the whole collection with a read size of 16K

I will be monitoring while fragmentation stacks up and report back if
something bad happens."

Spock, please let me know if you have any new results.

Thanks!