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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 BBD7AC432C0 for ; Mon, 18 Nov 2019 14:04:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 86FB820722 for ; Mon, 18 Nov 2019 14:04:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 86FB820722 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 14BE96B0003; Mon, 18 Nov 2019 09:04:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FD736B0006; Mon, 18 Nov 2019 09:04:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2F506B0007; Mon, 18 Nov 2019 09:04:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0254.hostedemail.com [216.40.44.254]) by kanga.kvack.org (Postfix) with ESMTP id D9A4C6B0003 for ; Mon, 18 Nov 2019 09:04:08 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 7E1C1181AEF07 for ; Mon, 18 Nov 2019 14:04:08 +0000 (UTC) X-FDA: 76169567376.02.play54_7b6a0fa733d58 X-HE-Tag: play54_7b6a0fa733d58 X-Filterd-Recvd-Size: 3487 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Mon, 18 Nov 2019 14:04:07 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 9ECC6ADDD; Mon, 18 Nov 2019 14:04:06 +0000 (UTC) Date: Mon, 18 Nov 2019 15:04:05 +0100 From: Michal Hocko To: Hillf Danton Cc: linux-mm , Rong Chen , linux-kernel Subject: Re: [RFC v3] memcg: add memcg lru Message-ID: <20191118140405.GD14255@dhcp22.suse.cz> References: <20191118125014.11516-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191118125014.11516-1-hdanton@sina.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 18-11-19 20:50:14, Hillf Danton wrote: > > On Mon, 18 Nov 2019 11:29:50 +0100 Michal Hocko wrote: > > > > On Sun 17-11-19 19:35:26, Hillf Danton wrote: > > > > > > Currently soft limit reclaim (slr) is frozen, see > > > Documentation/admin-guide/cgroup-v2.rst for reasons. > > > > > > This work adds memcg hook into kswapd's logic to bypass slr, paving > > > a brick for its cleanup later. > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > Finally new hook is added with slr's two problems addressed i.e. > > > hierarchy-unaware reclaim and overreclaim. > > > > > > Thanks to Rong Chen for testing. > > > 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. > > > 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. OK, that part was obviously broken in the previous version. But please read the whole feedback I (and Johannes) have provided. Besides that I would consider it polite to summarize the previous version which received to NAKs from maintainers and explain why you believe the code has addressed that problem. > 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. Let me ask differently. There must be a reason you have spent time on developing this feature. There must be a usecase you are targetting. Can you describe it so that we can evaluate pros and cons? -- Michal Hocko SUSE Labs