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:     Dexuan Cui <decui@microsoft.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Kernel Team <Kernel-team@fb.com>,
        "Shakeel Butt" <shakeelb@google.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Tejun Heo <tj@kernel.org>, Rik van Riel <riel@surriel.com>,
        Konstantin Khlebnikov <koct9i@gmail.com>,
        Matthew Wilcox <willy@infradead.org>,
        "Stable@vger.kernel.org" <Stable@vger.kernel.org>
Subject: Re: Will the recent memory leak fixes be backported to longterm
 kernels?
Thread-Topic: Will the recent memory leak fixes be backported to longterm
 kernels?
Thread-Index: AdRyQEG5VIfdELkdR3eQ5BGm0rZVc///mGwAgACTWwCAAFjogIAADIgAgAB8LwD//41GgIAAfX+AgAAJg4A=
Date:   Fri, 2 Nov 2018 17:25:58 +0000
Message-ID: <20181102172547.GA19042@tower.DHCP.thefacebook.com>
References: <PU1P153MB0169CB6382E0F047579D111DBFCF0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
 <20181102005816.GA10297@tower.DHCP.thefacebook.com>
 <PU1P153MB0169FE681EF81BCE81B005A1BFCF0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
 <20181102073009.GP23921@dhcp22.suse.cz>
 <20181102154844.GA17619@tower.DHCP.thefacebook.com>
 <20181102161314.GF28039@dhcp22.suse.cz>
 <20181102162237.GB17619@tower.DHCP.thefacebook.com>
 <20181102165147.GG28039@dhcp22.suse.cz>
In-Reply-To: <20181102165147.GG28039@dhcp22.suse.cz>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:200::4:b8f1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;BY2PR15MB0837;20:x3Gt0p+s9VTu3seIoTo3mQWMVaueIP4Zd8oMMcaOgGGMF/BO/lpB6Eq1iI18+O4ElXEcjxWhrvjsG3Uyyv3ZmVHVWkb5uFFkJt20oHMT/8sCmB/Eh+UKY0ZI/tVvPI/FK6FdN2dC66BV/YxtiDsHw7wsy4UvOsQUI5pw6spP0JM=
x-ms-office365-filtering-correlation-id: 479e3d03-7051-4904-ec18-08d640e83d68
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020);SRVR:BY2PR15MB0837;
x-ms-traffictypediagnostic: BY2PR15MB0837:
x-microsoft-antispam-prvs: <BY2PR15MB083743E1CACC52C9CE0A7F60BECF0@BY2PR15MB0837.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)(5005006)(8121501046)(3231382)(11241501184)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095);SRVR:BY2PR15MB0837;BCL:0;PCL:0;RULEID:;SRVR:BY2PR15MB0837;
x-forefront-prvs: 08444C7C87
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(396003)(136003)(376002)(366004)(346002)(39860400002)(189003)(199004)(52314003)(6116002)(1076002)(11346002)(446003)(476003)(93886005)(2906002)(316002)(8936002)(8676002)(81156014)(81166006)(68736007)(46003)(6506007)(386003)(33896004)(76176011)(86362001)(486006)(256004)(14444005)(102836004)(54906003)(52116002)(99286004)(186003)(25786009)(39060400002)(4326008)(9686003)(71200400001)(6512007)(53936002)(7736002)(33656002)(305945005)(7416002)(2900100001)(6436002)(6916009)(105586002)(106356001)(14454004)(71190400001)(6246003)(6486002)(478600001)(5660300001)(229853002)(97736004)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR15MB0837;H:BY2PR15MB0167.namprd15.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1;
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
x-microsoft-antispam-message-info: zsQDBpuCnSED0VFfx3vtKBi0c1B0vUh5n+2058lyxkvoJHJe1R0LnbyrnlCynDw/mxIspTSUvxElYoE2PZtqkWoiX3MN+qSdZzvwVthrfA+cG5fc6jsHimDt3wNbI4UFMYTxbP4iR4z2lF5VEHnNHFKN1XuULrt8xRKTk9Uh0Lic4D28h+ghDuH5r6MGvSyD9lVa+o+VfNOXtQA18AMd1UgBhwfcllnko17J0yR/x02J9oydu2aI/csb822yFT3FGCK4UB76V4fbm+6pf/gFtU5/OSBY7q53eEVYTvUUaMgCbQEnnDlOke7hZ5Z6+0dg19eWxL0F6xywNu1Gb8JJZk+0lgurN+gy0RUVfJRztYE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DFBA2EC09ED4C44691CFA9FBFB66BF56@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 479e3d03-7051-4904-ec18-08d640e83d68
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2018 17:25:58.0998
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0837
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-02_10:,,
 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, Nov 02, 2018 at 05:51:47PM +0100, Michal Hocko wrote:
> On Fri 02-11-18 16:22:41, Roman Gushchin wrote:
> > On Fri, Nov 02, 2018 at 05:13:14PM +0100, Michal Hocko wrote:
> > > On Fri 02-11-18 15:48:57, Roman Gushchin wrote:
> > > > On Fri, Nov 02, 2018 at 09:03:55AM +0100, Michal Hocko wrote:
> > > > > On Fri 02-11-18 02:45:42, Dexuan Cui wrote:
> > > > > [...]
> > > > > > I totally agree. I'm now just wondering if there is any tempora=
ry workaround,
> > > > > > even if that means we have to run the kernel with some features=
 disabled or
> > > > > > with a suboptimal performance?
> > > > >=20
> > > > > One way would be to disable kmem accounting (cgroup.memory=3Dnokm=
em kernel
> > > > > option). That would reduce the memory isolation because quite a l=
ot of
> > > > > memory will not be accounted for but the primary source of in-fli=
ght and
> > > > > hard to reclaim memory will be gone.
> > > >=20
> > > > In my experience disabling the kmem accounting doesn't really solve=
 the issue
> > > > (without patches), but can lower the rate of the leak.
> > >=20
> > > This is unexpected. 90cbc2508827e was introduced to address offline
> > > memcgs to be reclaim even when they are small. But maybe you mean tha=
t
> > > we still leak in an absence of the memory pressure. Or what does prev=
ent
> > > memcg from going down?
> >=20
> > There are 3 independent issues which are contributing to this leak:
> > 1) Kernel stack accounting weirdness: processes can reuse stack account=
ed to
> > different cgroups. So basically any running process can take a referenc=
e to any
> > cgroup.
>=20
> yes, but kmem accounting should rule that out, right? If not then this
> is a clear bug and easy to backport because that would mean to add a
> missing memcg_kmem_enabled check.

Yes, you're right, disabling kmem accounting should mitigate this problem.

>=20
> > 2) We do forget to scan the last page in the LRU list. So if we ended u=
p with
> > 1-page long LRU, it can stay there basically forever.
>=20
> Why=20
> 		/*
> 		 * If the cgroup's already been deleted, make sure to
> 		 * scrape out the remaining cache.
> 		 */
> 		if (!scan && !mem_cgroup_online(memcg))
> 			scan =3D min(size, SWAP_CLUSTER_MAX);
>=20
> in get_scan_count doesn't work for that case?

No, it doesn't. Let's look at the whole picture:

		size =3D lruvec_lru_size(lruvec, lru, sc->reclaim_idx);
		scan =3D size >> sc->priority;
		/*
		 * If the cgroup's already been deleted, make sure to
		 * scrape out the remaining cache.
		 */
		if (!scan && !mem_cgroup_online(memcg))
			scan =3D min(size, SWAP_CLUSTER_MAX);

If size =3D=3D 1, scan =3D=3D 0 =3D> scan =3D min(1, 32) =3D=3D 1.
And after proportional adjustment we'll have 0.

So, disabling kmem accounting mitigates 2 other issues, but not this one.

Anyway, I'd prefer to wait a bit for test results, and backport the whole
series as a whole.

Thanks!