10

In cgroup v1, we can read memory.max_usage_in_bytes to get the maximum memory usage during program runtime. But I didn't find similar function in cgroup v2.

Can cgroup v2 provide the same function? Or can we only do it by reading memory.current frequently (say every 10ms)?

English is not my native language; please excuse typing errors.

Improve this question
5
  • Hello, have you found a solution other than polling for memory.current? Commented May 4, 2021 at 8:33
  • @yaqwsx Yes, I ended up using getrusage#ru_maxrss (man7.org/linux/man-pages/man2/getrusage.2.html) to implement my requirements Commented May 6, 2021 at 9:37
  • 1
    But that uses rlimits, not cgroups if I understand correctly. I would like to get a memory consumption of the whole cgroup (and I have no reliable way of tracking the processes created inside the group). Commented May 6, 2021 at 13:14
  • Hm, it's so weird it is missing in cgroups v2, our CI workflows are relying on /sys/fs/cgroup/memory/memory.max_usage_in_bytes to determine max memory consumption at the end of the jobs.. Would be nice if this could be added back Commented Dec 15, 2022 at 20:03
  • Just hit this as well, as I look into migrating to cgroups v2 and we relied on the cgroups-based accounting of max_usage_in_bytes Commented Feb 16, 2023 at 21:28

1 Answer 1

Reset to default
6

With commit 8e20d4b332660a32e842e20c34cfc3b3456bc6dc (Fri May 13 16:48:57 2022 -0700) which first arrived in the 5.19 kernel tree, the memory.peak interface for cgroup v2 was introduced.

memory.peak is the equivalent to memory.max_usage_in_bytes in version 1, and exposes the value of memcg->watermark.

This value represents the max memory usage recorded for the cgroup and its descendants since the creation of the cgroup, in non-root cgroups.

$ cat memory.peak 13356507136

It's been backported to RHEL 9.3 in commit 8f095dc4e94f4e.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

For general kernel, v5.19+ is needed github.com/torvalds/linux/commit/…
But note that memory.current and therefore memory.peak do include inactive_file, among others. This means that this is not accounting just for the RSS of the process, but any memory used by the process. That might be inconvenient for users that just want to know how much memory did the process use, but not how much file cached memory was used due to creating files in the filesystem and the kernel caching them.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.