opencontainers / opencontainers/runc
cgroup v2 root stats should not be calculated as v1
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 13.5k
- Forks
- 2.3k
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 30
Description
Description
From the comments in https://github.com/opencontainers/runc/blob/main/libcontainer/cgroups/fs2/memory.go#L218, it appears the root stats of cgroup v2 was collected in a way to be similar to how v1 is implemented. My understanding, root stats v2 should be collected as memory.current in non-root cgroups, which is supposed to be total memory as opposed to just anon + file.
This issue causes missing a visible amount memory not counted in Usage (e.g. kernel memory) and is misleading. I propose using the value from /proc/meminfo to get the total memory usage for root stat.
Steps to reproduce the issue
- run a kubelet
- curl localhost:10255/stats/summary to check the root stats
- stats got from step 2 do not match the system memory usage
Describe the results you received and expected
root stats' usageBytes should match system memory usage
What version of runc are you using?
runc version 1.1.7
commit: a916309fff0f838eb94e928713dbc3c0d0ac7aa4
spec: 1.0.2-dev
go: go1.20.5
libseccomp: 2.5.4
Host OS information
No response
Host kernel information
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read libcontainer/cgroups/fs2/memory.go around line 218 and compare how root and non-root cgroup v2 memory stats are collected. Check how /proc/meminfo could provide the proposed root value, then reproduce the discrepancy with kubelet and curl localhost:10255/stats/summary. Done means root stats usageBytes match system memory usage without applying the v1 calculation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, linux
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100