From: Roman Gushchin <roman.gushchin@linux.dev>
To: Chris Down <chris@chrisdown.name>
Cc: "zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
ke wang <ke.wang@unisoc.com>,
Zhaoyang Huang <huangzhaoyang@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org
Subject: Re: [RFC PATCH] cgroup: introduce proportional protection on memcg
Date: Thu, 24 Mar 2022 09:23:44 -0700 [thread overview]
Message-ID: <FE4CCCF9-CF08-424B-85D0-B5C1BA63329D@linux.dev> (raw)
In-Reply-To: <Yjx/3yi7BfH7wLPz@chrisdown.name>
It seems like what’s being proposed is an ability to express the protection in % of the current usage rather than an absolute number.
It’s an equivalent for something like a memory (reclaim) priority: e.g. a cgroup with 80% protection is _always_ reclaimed less aggressively than one with a 20% protection.
That said, I’m not a fan of this idea.
It might make sense in some reasonable range of usages, but if your workload is simply leaking memory and growing indefinitely, protecting it seems like a bad idea. And the first part can be easily achieved using an userspace tool.
Thanks!
> On Mar 24, 2022, at 7:33 AM, Chris Down <chris@chrisdown.name> wrote:
>
> I'm confused by the aims of this patch. We already have proportional reclaim for memory.min and memory.low, and memory.high is already "proportional" by its nature to drive memory back down behind the configured threshold.
>
> Could you please be more clear about what you're trying to achieve and in what way the existing proportional reclaim mechanisms are insufficient for you?
>
next prev parent reply other threads:[~2022-03-24 16:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-24 9:22 zhaoyang.huang
2022-03-24 14:27 ` Chris Down
2022-03-24 16:23 ` Roman Gushchin [this message]
2022-03-25 3:10 ` Zhaoyang Huang
2022-03-25 3:02 ` Zhaoyang Huang
2022-03-25 3:08 ` Zhaoyang Huang
2022-03-25 12:49 ` Michal Hocko
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=FE4CCCF9-CF08-424B-85D0-B5C1BA63329D@linux.dev \
--to=roman.gushchin@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=chris@chrisdown.name \
--cc=hannes@cmpxchg.org \
--cc=huangzhaoyang@gmail.com \
--cc=ke.wang@unisoc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=vdavydov.dev@gmail.com \
--cc=zhaoyang.huang@unisoc.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