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:     Sasha Levin <sashal@kernel.org>
CC:     Greg KH <greg@kroah.com>, Michal Hocko <mhocko@kernel.org>,
        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+A//+UKoCAAHungP//qWqAAI/9poAKbIt2AAZlvz8AAAuwAYA=
Date:   Wed, 30 Jan 2019 05:58:42 +0000
Message-ID: <20190130055834.GC2107@castle.DHCP.thefacebook.com>
References: <20181102154844.GA17619@tower.DHCP.thefacebook.com>
 <20181102161314.GF28039@dhcp22.suse.cz>
 <20181102162237.GB17619@tower.DHCP.thefacebook.com>
 <20181102165147.GG28039@dhcp22.suse.cz>
 <20181102172547.GA19042@tower.DHCP.thefacebook.com>
 <20181102174823.GI28039@dhcp22.suse.cz>
 <20181102193827.GA18024@castle.DHCP.thefacebook.com>
 <20181105092053.GC4361@dhcp22.suse.cz> <20181228105008.GB15967@kroah.com>
 <20190130002356.GQ3973@sasha-vm>
In-Reply-To: <20190130002356.GQ3973@sasha-vm>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:180::1:e58d]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;BN8PR15MB2660;20:ivn52B2lGg81h7huiwy5Fz4iBUhkMX6yrRwwyt3QtLEQ+bLBAvDqG9XxaYRnkI4K8MSR3Qc5c8DkqCpdpUGYwFLkpLgZWrAkF1SdWebkYVxS8RsMl65bUUie4rmxUcXYi4lUK5wdWNm6SphsM3J1FG1wYrIEzFxgwYRPKRxduAU=
x-ms-office365-filtering-correlation-id: f7714dc6-dc35-4041-d020-08d68677fd2a
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020);SRVR:BN8PR15MB2660;
x-ms-traffictypediagnostic: BN8PR15MB2660:
x-microsoft-antispam-prvs: <BN8PR15MB2660A0E7EFEB372ED93E3FE3BE900@BN8PR15MB2660.namprd15.prod.outlook.com>
x-forefront-prvs: 0933E9FD8D
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(136003)(366004)(346002)(376002)(39860400002)(396003)(189003)(199004)(93886005)(6436002)(33896004)(966005)(8936002)(11346002)(229853002)(14454004)(52116002)(102836004)(6486002)(33656002)(106356001)(6506007)(316002)(386003)(105586002)(6246003)(99286004)(54906003)(46003)(76176011)(86362001)(97736004)(53936002)(6306002)(9686003)(39060400002)(6512007)(186003)(81156014)(256004)(7416002)(25786009)(2906002)(5024004)(6116002)(446003)(1076003)(4326008)(305945005)(6916009)(478600001)(476003)(486006)(8676002)(68736007)(81166006)(71200400001)(71190400001)(7736002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN8PR15MB2660;H:BN8PR15MB2626.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-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: JSSnj+ol5PVV/6rAMm21DQW2icnhG0lQan1Z1TvsfEKjjE62jOUXfYt1BU9N3hcsT5Gl2lI6RCnLahVfIuv2jK2fJqnoZBFHaEgi8vbWfudqaJ5LURDIgvQ83isZB0e2oNd4+11WOgpisCyuOdSfiupAGW6RglBzfxHuN9FId6CCWrgKm9bOxD/czsUsb7gf9ipus7sVLH0RPywlBkcRuO5GHfMSXo0vGGXKXpogG21VM4PTBeMYny78mrmqJTZHMyjqd7Ih19Qnrm9c6nguU+yt3OPj1pSnEr35xAGlVSCI16ru8l3w45xYmRedzOzN6YjDboj64819wfbtnVhdNI7lch427RYCCOuE40gaW3xLCxT0ZfyQLLmvFDie22N8Ui97GNFM2MoaK9nxNA9iRs38MA51wiDqWqiBuLF8td8=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A448C720D72766408B6E0024614816BA@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f7714dc6-dc35-4041-d020-08d68677fd2a
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2019 05:58:38.5656
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB2660
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-30_05:,,
 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 Tue, Jan 29, 2019 at 07:23:56PM -0500, Sasha Levin wrote:
> On Fri, Dec 28, 2018 at 11:50:08AM +0100, Greg KH wrote:
> > On Mon, Nov 05, 2018 at 10:21:23AM +0100, Michal Hocko wrote:
> > > On Fri 02-11-18 19:38:35, Roman Gushchin wrote:
> > > > On Fri, Nov 02, 2018 at 06:48:23PM +0100, Michal Hocko wrote:
> > > > > On Fri 02-11-18 17:25:58, Roman Gushchin wrote:
> > > > > > On Fri, Nov 02, 2018 at 05:51:47PM +0100, Michal Hocko wrote:
> > > > > > > On Fri 02-11-18 16:22:41, Roman Gushchin wrote:
> > > > > [...]
> > > > > > > > 2) We do forget to scan the last page in the LRU list. So i=
f we ended up with
> > > > > > > > 1-page long LRU, it can stay there basically forever.
> > > > > > >
> > > > > > > Why
> > > > > > > 		/*
> > > > > > > 		 * 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);
> > > > > > >
> > > > > > > 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.
> > > > >
> > > > > My friday brain hurst when looking at this but if it doesn't work=
 as
> > > > > advertized then it should be fixed. I do not see any of your patc=
hes to
> > > > > touch this logic so how come it would work after them applied?
> > > >
> > > > This part works as expected. But the following
> > > > 	scan =3D div64_u64(scan * fraction[file], denominator);
> > > > reliable turns 1 page to scan to 0 pages to scan.
> > >=20
> > > OK, 68600f623d69 ("mm: don't miss the last page because of round-off
> > > error") sounds like a good and safe stable backport material.
> >=20
> > Thanks for this, now queued up.
> >=20
> > greg k-h
>=20
> It seems that 172b06c32b949 ("mm: slowly shrink slabs with a relatively
> small number of objects") and a76cf1a474d ("mm: don't reclaim inodes
> with many attached pages") cause a regression reported against the 4.19
> stable tree: https://bugzilla.kernel.org/show_bug.cgi?id=3D202441 .
>=20
> Given the history and complexity of these (and other patches from that
> series) it would be nice to understand if this is something that will be
> fixed soon or should we look into reverting the series for now?

In that thread I've just suggested to give a chance to Rik's patch, which
hopefully will mitigate or easy the regression (
https://lkml.org/lkml/2019/1/28/1865 ).

Of course, we can simple revert those changes, but this will re-introduce
the memory leak, so I'd leave it as a last option.

Thanks!