Thread (11 messages) 11 messages, 4 authors, 2021-06-04

Re: [RFC 0/7] Introduce memory allocation speed throttle in memcg

From: yulei zhang <hidden>
Date: 2021-06-04 10:21:28
Also in: linux-mm

On Thu, Jun 3, 2021 at 7:38 PM Chris Down [off-list ref] wrote:
yulei zhang writes:
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help