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:     Spock <dairinin@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Rik van Riel <riel@surriel.com>,
        "Johannes Weiner" <hannes@cmpxchg.org>,
        Vladimir Davydov <vdavydov.dev@gmail.com>,
        Shakeel Butt <shakeelb@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Sasha Levin <alexander.levin@microsoft.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Memory management issue in 4.18.15
Thread-Topic: Memory management issue in 4.18.15
Thread-Index: AQHUaeHkHk+DbEcbikCQiNZLx8ZaF6Urh5iA
Date:   Mon, 22 Oct 2018 17:35:57 +0000
Message-ID: <20181022173550.GA9592@tower.DHCP.thefacebook.com>
References: <CADa=ObrwYaoNFn0x06mvv5W1F9oVccT5qjGM8qFBGNPoNuMUNw@mail.gmail.com>
 <20181022083322.GE32333@dhcp22.suse.cz>
In-Reply-To: <20181022083322.GE32333@dhcp22.suse.cz>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:200::4:c82f]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;BY2PR15MB0262;20:NQj/MbdRkxC2/5xYqka/cT1065Es+uTRllx0bSORvyVvCnK1TqWQsU3Ct/4gIIFIh1QDLx8B78pf+fIHsx8LJaDVIsIXPcVBtbwwoJraCbs0obI0f6CxwsmUiEfs8C8dsrhRfoGr2DQyato30mut68oxX149yv2MhEPj+OJ7bCo=
x-ms-office365-filtering-correlation-id: e0e8f5cb-70c8-46c3-7018-08d63844d309
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020);SRVR:BY2PR15MB0262;
x-ms-traffictypediagnostic: BY2PR15MB0262:
x-microsoft-antispam-prvs: <BY2PR15MB02620EFBBEE568FD0ABCD1CFBEF40@BY2PR15MB0262.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(11241501184)(944501410)(52105095)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095);SRVR:BY2PR15MB0262;BCL:0;PCL:0;RULEID:;SRVR:BY2PR15MB0262;
x-forefront-prvs: 08331F819E
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(39860400002)(376002)(396003)(136003)(366004)(346002)(199004)(189003)(46003)(76176011)(5024004)(4326008)(11346002)(2900100001)(7736002)(386003)(256004)(486006)(25786009)(39060400002)(1076002)(446003)(33656002)(476003)(6116002)(71190400001)(81156014)(71200400001)(8676002)(9686003)(14454004)(2906002)(81166006)(6512007)(6436002)(97736004)(53936002)(478600001)(6486002)(186003)(5250100002)(6246003)(105586002)(86362001)(229853002)(106356001)(33896004)(68736007)(8936002)(305945005)(5660300001)(52116002)(6916009)(7416002)(99286004)(102836004)(6506007)(54906003)(316002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR15MB0262;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: 1XEZFkTzSf5herXtsPYet3qievwCdapSds/xSF4EZf38/Pb03H0lQ6Dlrl9NfSVf0PuFvxZyiMrFrq9qAETF1HBrLNjYxe0hnqCdsKfo6ZW0bOKQldcxIuuSaceZd7DbIAHQuvcEwJPWAujtYUFRFwx4GE9ezEJDRTkJm2bPCcB0M229eVXUHrl1C/KCGy6boI7rQSQ6rmtdFYfQ6Ms+oZ1pP6GfmxS/ljZxbW05rTYcN9Gy05ClnLeH+ulKszvbx0CkmjDu1K95qQjIN3LUlrNapQDEoP1nxSSTm1QpnFfFS0Up/1q4639TzQbLEsJjX/Au1MTqGbn+w2U1XhBIWCmlNlcL9mi8Z7llScbWb38=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F1A88CC12485E84292DE324AD647ABEF@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e0e8f5cb-70c8-46c3-7018-08d63844d309
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2018 17:35:57.4828
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0262
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-22_11:,,
 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 Mon, Oct 22, 2018 at 10:33:22AM +0200, Michal Hocko wrote:
> Cc som more people.
>=20
> I am wondering why 172b06c32b94 ("mm: slowly shrink slabs with a
> relatively small number of objects") has been backported to the stable
> tree when not marked that way. Put that aside it seems likely that the
> upstream kernel will have the same issue I suspect. Roman, could you
> have a look please?

So, the problem is probably caused by the unused inode eviction code:
inode_lru_isolate() invalidates all pages belonging to an unreferenced
clean inode at once, even if the goal was to scan (and potentially free)
just one inode (or any other slab object).

Spock's workload, as described, has few large files in the pagecache,
so it becomes noticeable. A small pressure applied on inode cache
surprisingly results in cleaning up significant percentage of the memory.

It happened before my change too, but was probably less noticeable, because
usually required higher memory pressure to happen. So, too aggressive recla=
im
was less unexpected.

How to fix this?

It seems to me, that we shouldn't try invalidating pagecache pages from
the inode reclaim path at all (maybe except inodes with only few pages).
If an inode has a lot of attached pagecache, let it be evicted "naturally",
through file LRU lists.
But I need to perform some real-life testing on how this will work.

Thanks!