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.7 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 7E525C43603 for ; Thu, 19 Dec 2019 08:59:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1C0B02064B for ; Thu, 19 Dec 2019 08:59:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C0B02064B 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 7AC678E015C; Thu, 19 Dec 2019 03:59:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 736FC8E00F5; Thu, 19 Dec 2019 03:59:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6237E8E015C; Thu, 19 Dec 2019 03:59:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) by kanga.kvack.org (Postfix) with ESMTP id 480E18E00F5 for ; Thu, 19 Dec 2019 03:59:44 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 005EF2494 for ; Thu, 19 Dec 2019 08:59:43 +0000 (UTC) X-FDA: 76281293046.29.work53_8f0be7c98c83f X-HE-Tag: work53_8f0be7c98c83f X-Filterd-Recvd-Size: 4131 Received: from out30-42.freemail.mail.aliyun.com (out30-42.freemail.mail.aliyun.com [115.124.30.42]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Thu, 19 Dec 2019 08:59:42 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04395;MF=teawaterz@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0TlL..BY_1576745976; Received: from 30.30.208.2(mailfrom:teawaterz@linux.alibaba.com fp:SMTPD_---0TlL..BY_1576745976) by smtp.aliyun-inc.com(127.0.0.1); Thu, 19 Dec 2019 16:59:37 +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: <20191218140952.GA255739@chrisdown.name> Date: Thu, 19 Dec 2019 16:59:36 +0800 Cc: hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org, guro@fb.com, shakeelb@google.com, 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: <25AA9500-B249-42C2-B162-2B8D4EE83BB0@linux.alibaba.com> References: <1576662179-16861-1-git-send-email-teawaterz@linux.alibaba.com> <20191218140952.GA255739@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=C218=C8=D5=A3=AC22:09=A3=ACChris Down = =D0=B4=B5=C0=A3=BA >=20 > Hi Hui, >=20 > In general cgroup v1 is in maintenance mode -- that is, excepting = specific bugfixes, we don't plan to add new features. Hi Chris, Thanks for your review. I will move to v2. >=20 > Hui Zhu writes: >> Currently, memcg has some config to limit memory usage and config >> the shrink behavior. >> In the memory-constrained environment, put different priority tasks >> into different cgroups with different memory limits to protect the >> performance of the high priority tasks. Because the global memory >> shrink will affect the performance of all tasks. The memory limit >> cgroup can make shrink happen inside the cgroup. Then it can = decrease >> the memory shrink of the high priority task to protect its = performance. >>=20 >> But the memory footprint of the task is not static. It will change = as >> the working pressure changes. And the version changes will affect it = too. >> Then set the appropriate memory limit to decrease the global memory = shrink >> is a difficult job and lead to wasted memory or performance loss = sometimes. >>=20 >> This commit adds global shrink priority to memcg to try to handle = this >> problem. >=20 > I have significant concerns with exposing scan priority to userspace. = This is an incredibly difficult metric for users to reason about since = it's a reclaim implementation feature and would add to an already = confusing and fragmented API in v1. >=20 > Have you considered using memory protection (memory.low, memory.min) = for this instead? It sounds like it can achieve the results you want, in = that it allows you to direct and prioritise reclaim in a way that allows = for ballparking (ie. it is compatible with applications with variable = memory footprints). >=20 Memory.min, low, high can affect the global shrink behavior. They can = help task keep some pages to help protect performance. 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. Thanks, Hui > Thanks, >=20 > Chris