From: Chris Down <chris@chrisdown.name>
To: teawater <teawaterz@linux.alibaba.com>
Cc: hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com,
akpm@linux-foundation.org, guro@fb.com, shakeelb@google.com,
Yang Shi <yang.shi@linux.alibaba.com>,
tj@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: vmscan: memcg: Add global shrink priority
Date: Thu, 19 Dec 2019 11:26:18 +0000 [thread overview]
Message-ID: <20191219112618.GA72828@chrisdown.name> (raw)
In-Reply-To: <25AA9500-B249-42C2-B162-2B8D4EE83BB0@linux.alibaba.com>
Hi Hui,
teawater writes:
>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’t
>have enough pages to be dropped and system need more free page, shrink the
>high priority task’s pages. Because at this time, system’s 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.
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:
commit 9783aa9917f8ae24759e67bf882f1aba32fe4ea1
Author: Chris Down <chris@chrisdown.name>
Date: Sun Oct 6 17:58:32 2019 -0700
mm, memcg: proportional memory.{low,min} reclaim
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.
Thanks,
Chris
0: https://facebookmicrosites.github.io/cgroup2/docs/overview.html#case-study-the-fbtax2-project
next prev parent reply other threads:[~2019-12-19 11:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-18 9:42 [PATCH] mm: vmscan: memcg: Add global shrink priority Hui Zhu
2019-12-18 10:47 ` Yafang Shao
2019-12-19 9:04 ` teawater
2019-12-18 14:09 ` Chris Down
2019-12-19 8:59 ` teawater
2019-12-19 11:26 ` Chris Down [this message]
2019-12-20 7:48 ` teawater
2019-12-29 13:38 ` teawater
2019-12-29 14:02 ` Chris Down
2019-12-30 3:32 ` teawater
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191219112618.GA72828@chrisdown.name \
--to=chris@chrisdown.name \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=shakeelb@google.com \
--cc=teawaterz@linux.alibaba.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vdavydov.dev@gmail.com \
--cc=yang.shi@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).