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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,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 3D9CFC4727C for ; Tue, 29 Sep 2020 16:02:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B9F7220936 for ; Tue, 29 Sep 2020 16:02:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=suse.com header.i=@suse.com header.b="Dln7ZaBi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B9F7220936 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C08056B005C; Tue, 29 Sep 2020 12:02:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB87A6B005D; Tue, 29 Sep 2020 12:02:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF5918E0001; Tue, 29 Sep 2020 12:02:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0202.hostedemail.com [216.40.44.202]) by kanga.kvack.org (Postfix) with ESMTP id 9A3726B005C for ; Tue, 29 Sep 2020 12:02:34 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4B562181AE865 for ; Tue, 29 Sep 2020 16:02:34 +0000 (UTC) X-FDA: 77316566628.27.day61_0e022f22718b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id BC8D83E36F for ; Tue, 29 Sep 2020 16:02:10 +0000 (UTC) X-HE-Tag: day61_0e022f22718b X-Filterd-Recvd-Size: 3403 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Sep 2020 16:02:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1601395328; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Oqm8kelAsJrUo4JsbkYwsN07n5h2pe7l50xG9+frB/U=; b=Dln7ZaBimqqrmriuucaYPXeerskA9Gh7mZItb6jhy4KITYpOuSVhlB4CbDsZEFL3a0GmMi pGTDkYvXP7TM83vH+/Apip7OuXwPz0yjdb/bFOtEBMXK/l902/dqiVgWB7DiYJarBsqnYg DBv13pKcBSD8hOjBKLxAxWTECRntnls= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D3E97AC12; Tue, 29 Sep 2020 16:02:08 +0000 (UTC) Date: Tue, 29 Sep 2020 18:02:07 +0200 From: Michal Hocko To: zhong jiang Cc: hannes@cmpxchg.org, akpm@linux-foundation.org, linux-mm@kvack.org Subject: Re: [PATCH] mm: Do not deactivate when the cgroup has plenty inactive page Message-ID: <20200929160207.GK2277@dhcp22.suse.cz> References: <1601034552-95831-1-git-send-email-zhongjiang-ali@linux.alibaba.com> <20200925120758.GF3389@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.001930, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun 27-09-20 10:39:22, zhong jiang wrote: >=20 > On 2020/9/25 8:07 =E4=B8=8B=E5=8D=88, Michal Hocko wrote: > > On Fri 25-09-20 19:49:12, zhongjiang-ali wrote: > > > After appling the series patches(mm: fix page aging across multiple= cgroups), > > > cgroup memory reclaim strategy is based on reclaim root's inactive:= active > > > ratio. if the target lruvec need to deactivate, its children cgroup= also will > > > deactivate. That will result in hot page to be reclaimed and other = cgroup's > > > cold page will be left, which is not expected. > > >=20 > > > The patch will not force deactivate when inactive_is_low is not tru= e unless > > > we has scanned the inactive list and memory is unable to reclaim. > > Do you have any data to present? >=20 > I write an testcase that cgroup B has a lot of hot pagecache and cgroup= C=C2=A0 > is full of cold pagecache.=C2=A0 and >=20 > their parent cgroup A will trigger the reclaim due of it's limit has be= en > breached. >=20 >=20 > The testcase should assume that we should not reclaim the=C2=A0 hot pag= ecache in > cgroup B because C has >=20 > plenty cold pagecache.=C2=A0=C2=A0 Unfortunately,=C2=A0 I can see cgrou= p B hot pagecache > has been decreased when >=20 > cgroup A trigger the reclaim. Thank you, this is more or less what've expected from your initial description. An extended form would be preferable for the changelog to make the setup more clear. But you still haven't quantified the effect. It would be also good to describe what is the effect on the workload described by 53138cea7f39 ("mm: vmscan: move file exhaustion detection to the node level"). A more extended description on the implementation would be nice as well. --=20 Michal Hocko SUSE Labs