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.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY 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 2D52FC2D0CE for ; Sun, 29 Dec 2019 13:39:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C35F120718 for ; Sun, 29 Dec 2019 13:39:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C35F120718 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 230F88E0005; Sun, 29 Dec 2019 08:39:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E2D18E0003; Sun, 29 Dec 2019 08:39:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F85F8E0005; Sun, 29 Dec 2019 08:39:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0029.hostedemail.com [216.40.44.29]) by kanga.kvack.org (Postfix) with ESMTP id EA71A8E0003 for ; Sun, 29 Dec 2019 08:39:34 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 89CD3248C for ; Sun, 29 Dec 2019 13:39:34 +0000 (UTC) X-FDA: 76318286268.03.iron97_708ebdfba8555 X-HE-Tag: iron97_708ebdfba8555 X-Filterd-Recvd-Size: 4249 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Sun, 29 Dec 2019 13:39:32 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R121e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e07486;MF=teawaterz@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0TmAx.Hp_1577626765; Received: from 30.39.3.192(mailfrom:teawaterz@linux.alibaba.com fp:SMTPD_---0TmAx.Hp_1577626765) by smtp.aliyun-inc.com(127.0.0.1); Sun, 29 Dec 2019 21:39:26 +0800 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [PATCH] mm: vmscan: memcg: Add global shrink priority From: teawater In-Reply-To: <20191219112618.GA72828@chrisdown.name> Date: Sun, 29 Dec 2019 21:38:00 +0800 Cc: Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Roman Gushchin , Shakeel Butt , Yang Shi , tj@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org Content-Transfer-Encoding: quoted-printable Message-Id: <1E6A7BC4-A983-4C65-9DA9-4D3A26D4D31D@linux.alibaba.com> References: <1576662179-16861-1-git-send-email-teawaterz@linux.alibaba.com> <20191218140952.GA255739@chrisdown.name> <25AA9500-B249-42C2-B162-2B8D4EE83BB0@linux.alibaba.com> <20191219112618.GA72828@chrisdown.name> To: Chris Down X-Mailer: Apple Mail (2.3445.104.11) 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: > =D4=DA 2019=C4=EA12=D4=C219=C8=D5=A3=AC19:26=A3=ACChris Down = =D0=B4=B5=C0=A3=BA >=20 > Hi Hui, >=20 > teawater writes: >> Memory.min, low, high can affect the global shrink behavior. They = can help task keep some pages to help protect performance. >>=20 >> But what I want is the low priority tasks (the tasks that performance = is not very important) do more shrink first. And when low priority = tasks doesn=A1=AFt have enough pages to be dropped and system need more = free page, shrink the high priority task=A1=AFs pages. Because at this = time, system=A1=AFs stable is more important than the performance of = priority task. >> With memory.min and memory.low, I have no idea to config them to = support this. That is why I add global shrink priority. >=20 > For sure, that's what I'm suggesting you use memory.{min,low} for -- = you define some subset of the cgroup hierarchy as "protected", and then = you bias reclaim away from protected cgroups (and thus *towards* = unprotected cgroups) by biasing the size of LRU scanning. See my patch = that went into 5.4 and the examples in the commit message: >=20 > commit 9783aa9917f8ae24759e67bf882f1aba32fe4ea1 > Author: Chris Down > Date: Sun Oct 6 17:58:32 2019 -0700 >=20 > mm, memcg: proportional memory.{low,min} reclaim >=20 > You can see how we're using memory.{low,min} to achieve this in this = case study[0]. It's not exactly equivalent technically to your solution, = but the end goals are similar. >=20 > Thanks, >=20 > Chris >=20 > 0: = https://facebookmicrosites.github.io/cgroup2/docs/overview.html#case-study= -the-fbtax2-project Hi Chris, I have another idea about global shrink priority. In the memory-constrained and complex multitasking environment such as = an Android system may require more complex performance priority. For example, the tasks of app in the font, they need high priority = because low priority will affect the user experience at once. The tasks of app in background should have lower priority than the first = one. And sometime, each app should have different priority. Because = some apps are frequently used. They should have high priority than = other background apps. The daemons should have lower priority than background apps. Because = most of them will not affect the user experience. Do you think this environment is suitable for global shrink priority. Best, Hui