From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4D2DC432C0 for ; Mon, 18 Nov 2019 12:50:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 610D12084D for ; Mon, 18 Nov 2019 12:50:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 610D12084D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D91F86B000D; Mon, 18 Nov 2019 07:50:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D43036B000E; Mon, 18 Nov 2019 07:50:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C318D6B0010; Mon, 18 Nov 2019 07:50:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0195.hostedemail.com [216.40.44.195]) by kanga.kvack.org (Postfix) with ESMTP id AD3A46B000D for ; Mon, 18 Nov 2019 07:50:29 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 62732440B for ; Mon, 18 Nov 2019 12:50:29 +0000 (UTC) X-FDA: 76169381778.08.game00_3e47ae7138758 X-HE-Tag: game00_3e47ae7138758 X-Filterd-Recvd-Size: 3120 Received: from r3-11.sinamail.sina.com.cn (r3-11.sinamail.sina.com.cn [202.108.3.11]) by imf19.hostedemail.com (Postfix) with SMTP for ; Mon, 18 Nov 2019 12:50:27 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([124.64.3.114]) by sina.com with ESMTP id 5DD2938F000061E9; Mon, 18 Nov 2019 20:50:25 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 11652449283212 From: Hillf Danton To: Michal Hocko Cc: Hillf Danton , linux-mm , Rong Chen , linux-kernel Subject: Re: [RFC v3] memcg: add memcg lru Date: Mon, 18 Nov 2019 20:50:14 +0800 Message-Id: <20191118125014.11516-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000053, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 18 Nov 2019 11:29:50 +0100 Michal Hocko wrote: >=20 > On Sun 17-11-19 19:35:26, Hillf Danton wrote: > >=20 > > Currently soft limit reclaim (slr) is frozen, see > > Documentation/admin-guide/cgroup-v2.rst for reasons. > >=20 > > This work adds memcg hook into kswapd's logic to bypass slr, paving > > a brick for its cleanup later. > >=20 > > After b23afb93d317 ("memcg: punt high overage reclaim to > > return-to-userland path"), high limit breachers (hlb) are reclaimed > > one after another spiraling up through the memcg hierarchy before > > returning to userspace. > >=20 > > The current memcg high work helps to add the lru because we get to > > collect hlb at zero price and in particular without adding changes > > to the high work's behavior. > >=20 > > Then a fifo list, which is essencially a simple copy of the page lru, > > is needed to facilitate queuing up hlb and ripping pages off them in > > round robin once kswapd starts doing its job. > >=20 > > Finally new hook is added with slr's two problems addressed i.e. > > hierarchy-unaware reclaim and overreclaim. > >=20 > > Thanks to Rong Chen for testing. >=20 Hey Michal Thanks for your comments, this time and previous. > You have ignored the previous review feedback again [1]. I have nacked > the patch on grounds that it is completely missing any real use case > scenario or any numbers suggesting there is an actual improvement. >=20 You are right though around half. After another peep at your comment on v2, I think you didn't approve the change added in high work to defer reclaim until kswapd becomes active with good reasoning. That defer is cut in v3. The added lru will take the place of the current slr, so slr's use cases apply to it with no exception, yes? Please feel free let us know what use cases else you may have interests in. And the concerned improvement is just on the table, Sir, if we fail to see regressions following lru, with no need to say the price we pay for maintaining hlb is close to zero for instance among others. Hillf > Please do not post new versions until you make those things clear. >=20 > [1] http://lkml.kernel.org/r/20191029083730.GC31513@dhcp22.suse.cz > --=20 > Michal Hocko > SUSE Labs