From: yulei zhang <yulei.kernel@gmail.com>
To: Chris Down <chris@chrisdown.name>
Cc: Shakeel Butt <shakeelb@google.com>, Tejun Heo <tj@kernel.org>,
Zefan Li <lizefan.x@bytedance.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Christian Brauner <christian@brauner.io>,
Cgroups <cgroups@vger.kernel.org>,
benbjiang@tencent.com, Wanpeng Li <kernellwp@gmail.com>,
Yulei Zhang <yuleixzhang@tencent.com>,
Linux MM <linux-mm@kvack.org>, Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <guro@fb.com>
Subject: Re: [RFC 0/7] Introduce memory allocation speed throttle in memcg
Date: Fri, 4 Jun 2021 18:15:02 +0800 [thread overview]
Message-ID: <CACZOiM03toiqcbtEd8LT26T2GtPsDaFj89o8rjEfELTw=KPvfg@mail.gmail.com> (raw)
In-Reply-To: <YLi/UeS71mk12VZ3@chrisdown.name>
On Thu, Jun 3, 2021 at 7:38 PM Chris Down <chris@chrisdown.name> wrote:
>
> yulei zhang writes:
> >Thanks. IMHO, there are differences between these two throttlings.
> >memory.high is a per-memcg throttle which targets to limit the memory
> >usage of the tasks in the cgroup. For the memory allocation speed throttle(MST),
> >the purpose is to avoid the memory burst in cgroup which would trigger
> >the global reclaim and affects the timing sensitive workloads in other cgroup.
> >For example, we have two pods with memory overcommit enabled, one includes
> >online tasks and the other has offline tasks, if we restrict the memory usage of
> >the offline pod with memory.high, it will lose the benefit of memory overcommit
> >when the other workloads are idle. On the other hand, if we don't
> >limit the memory
> >usage, it will easily break the system watermark when there suddenly has massive
> >memory operations. If enable MST in this case, we will be able to
> >avoid the direct
> >reclaim and leverage the overcommit.
>
> Having a speed throttle is a very primitive knob: it's hard to know what the
> correct values are for a user. That's one of the reasons why we've moved away
> from that kind of tunable for blkio.
>
> Ultimately, if you want work-conserving behaviour, why not use memory.low?
Thanks. But currently low and high are for cgroup v2 setting, do you
think we'd better
extend the same mechanism to cgroup v1?
next prev parent reply other threads:[~2021-06-04 10:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1622043596.git.yuleixzhang@tencent.com>
2021-05-26 20:52 ` Shakeel Butt
2021-05-31 12:11 ` yulei zhang
2021-05-31 18:20 ` Shakeel Butt
2021-06-01 14:45 ` Chris Down
2021-06-02 9:11 ` yulei zhang
2021-06-02 15:39 ` Shakeel Butt
2021-06-03 10:19 ` yulei zhang
2021-06-03 11:38 ` Chris Down
2021-06-04 10:15 ` yulei zhang [this message]
2021-06-04 11:51 ` Chris Down
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='CACZOiM03toiqcbtEd8LT26T2GtPsDaFj89o8rjEfELTw=KPvfg@mail.gmail.com' \
--to=yulei.kernel@gmail.com \
--cc=benbjiang@tencent.com \
--cc=cgroups@vger.kernel.org \
--cc=chris@chrisdown.name \
--cc=christian@brauner.io \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kernellwp@gmail.com \
--cc=linux-mm@kvack.org \
--cc=lizefan.x@bytedance.com \
--cc=mhocko@kernel.org \
--cc=shakeelb@google.com \
--cc=tj@kernel.org \
--cc=yuleixzhang@tencent.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