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:     Dexuan Cui <decui@microsoft.com>
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>,
        "Shakeel Butt" <shakeelb@google.com>,
        Michal Hocko <mhocko@kernel.org>,
        "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///mGwAgACTWwCAAAh7gA==
Date:   Fri, 2 Nov 2018 03:16:08 +0000
Message-ID: <20181102031600.GA15013@castle.DHCP.thefacebook.com>
References: <PU1P153MB0169CB6382E0F047579D111DBFCF0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
 <20181102005816.GA10297@tower.DHCP.thefacebook.com>
 <PU1P153MB0169FE681EF81BCE81B005A1BFCF0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
In-Reply-To: <PU1P153MB0169FE681EF81BCE81B005A1BFCF0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:180::1:b6e9]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;BY2PR15MB0808;20:PMAWzcaVQFr/L7Zl8/cxGiYtHNPypdOjjYgXjDln578PNNKZ0zCKLRhuvfi3HN6Hg04B5FYrcz+jrqXRsPI18GawXPkKoKD5dZqGgMmjX0+r8f/zvHlPDsT26XR1dgESMBlV4C7zrGo7IDEGNnxt/N4k/Un7b8yRRXUvYeAu+hs=
x-ms-office365-filtering-correlation-id: dfabeb83-979d-409b-6de8-08d640718834
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020);SRVR:BY2PR15MB0808;
x-ms-traffictypediagnostic: BY2PR15MB0808:
x-microsoft-antispam-prvs: <BY2PR15MB080868CD408F50AFB480BC43BECF0@BY2PR15MB0808.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(67672495146484);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(823302103)(10201501046)(3231382)(11241501184)(944501410)(52105095)(3002001)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991095);SRVR:BY2PR15MB0808;BCL:0;PCL:0;RULEID:;SRVR:BY2PR15MB0808;
x-forefront-prvs: 08444C7C87
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(396003)(39860400002)(136003)(346002)(376002)(366004)(51914003)(189003)(199004)(25786009)(14454004)(2900100001)(476003)(478600001)(4326008)(486006)(11346002)(6916009)(33896004)(6506007)(7416002)(102836004)(386003)(5660300001)(7736002)(6116002)(106356001)(71200400001)(52116002)(186003)(2906002)(68736007)(105586002)(71190400001)(8676002)(46003)(81156014)(8936002)(1511001)(81166006)(76176011)(1076002)(229853002)(446003)(5024004)(305945005)(14444005)(256004)(33656002)(9686003)(6246003)(316002)(39060400002)(99286004)(6486002)(86362001)(53936002)(6512007)(97736004)(6436002)(54906003)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR15MB0808;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: x45As4mM1KtPrKVU62C+Qjv0Ew3q+2mnmZPtG8b4UY2K8S9ONWUVCQ8+gB4cc4pklHyq+nprGZ6lb9LZwNV3+02sbDppjMvYbNLRcdaavVWj65nT6bYTgB8jgmD8DKJuY+fFXJ+d7vpPmljTWepJB7v3UHL5x7yBMUDpMjCH2SF3k2/Pm2PUClmuIPB7Y+TguPI75XdETiqsP71SOrwlvzPvzzQ0stwRlDomtc7jnbc9hyV/nxsamL/7gX89xgmSnVNAWlbZdeXFyeNb1qhoyJ0oKeNogChm0e7WqK08Z1LxAtIgKeGwAAgCU5QH9WOXIo73qviiyRMXEIlRVTAD/yDCOcwu6+TBzCqDApKEP0U=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8D6DDE4B74DB614E97CF0C7E6120702F@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dfabeb83-979d-409b-6de8-08d640718834
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2018 03:16:08.5858
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0808
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-02_01:,,
 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 02:45:42AM +0000, Dexuan Cui wrote:
> > From: Roman Gushchin <guro@fb.com>
> > Sent: Thursday, November 1, 2018 17:58
> >=20
> > On Fri, Nov 02, 2018 at 12:16:02AM +0000, Dexuan Cui wrote:
> > Hello, Dexuan!
> >=20
> > A couple of issues has been revealed recently, here are fixes
> > (hashes are from the next tree):
> >=20
> > 5f4b04528b5f mm: don't reclaim inodes with many attached pages
> > 5a03b371ad6a mm: handle no memcg case in memcg_kmem_charge()
> > properly
> >=20
> > These two patches should be added to the serie.
>=20
> Thanks for the new info!
> =20
> > Re stable backporting, I'd really wait for some time. Memory reclaim is=
 a
> > quite complex and fragile area, so even if patches are correct by thems=
elves,
> > they can easily cause a regression by revealing some other issues (as i=
t was
> > with the inode reclaim case).
>=20
> I totally agree. I'm now just wondering if there is any temporary workaro=
und,
> even if that means we have to run the kernel with some features disabled =
or
> with a suboptimal performance?

I don't think there is any, except not using memory cgroups at all.
Limiting the amount of cgroups which are created and destroyed helps too:
a faulty service running under systemd can be especially painful.

Thanks!