Fix get available memory to walk cgroup v2 ancestor chain#1824
Fix get available memory to walk cgroup v2 ancestor chain#1824
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
d08954d to
808f116
Compare
ae17f70 to
9fd4e7c
Compare
808f116 to
3d782ef
Compare
| copy-to-ecr: | ||
| name: Copy ${{ matrix.arch }} to ECR | ||
| needs: build | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
Note: This reduced the wait time for GH runners from ~15 min to seconds.
| None | ||
| } | ||
|
|
||
| fn get_available_memory_with<F>(read_file: F) -> Byte |
There was a problem hiding this comment.
I could see an argument for an info log in this function for what it resolved from where. Let me know if that's something you find desirable.
|
Container build errors are fixed in #1827 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3d782ef017
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
9fd4e7c to
c81ae74
Compare
3d782ef to
cc851e7
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cc851e7dbd
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
c81ae74 to
cc4fe22
Compare
cc851e7 to
a479460
Compare
|
I need to make a fresh build and test this further. Codex kept finding cgroup edge cases so I want to at least test our current setup (lading as is and lading as a target). |
a479460 to
db73f9e
Compare
|
I think the code looks good, but I'm hesitant to take on the complexity of cgroupv1 support. What environment needs this? Can we switch it to cgroupv2 instead? |
Let me run a test. I'll drop it and run a test. |
Can confirm, it was just our cgroupv2 implementation was wrong. Here are the logs with a fresh lading without any of the cgroupv1 stuff but with the changes to the cgroupv2: https://app.datadoghq.com/logs?query=job_id%3Af798fb29-9ba6-4bc7-9062-9248e739ff56%20%22amount%20of%20memory%22&agg_m=count&agg_m_source=base&agg_t=count&cols=host%2Cexperiment&messageDisplay=inline&refresh_mode=paused&storage=hot&stream_sort=time%2Cdesc&viz=stream&from_ts=1773919188864&to_ts=1773922788864&live=false We can see that the memory reported is exactly what we expect. |
db73f9e to
2619756
Compare
2619756 to
b573bc9
Compare
cc4fe22 to
6927271
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b573bc91e4
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
b573bc9 to
00cc251
Compare
Merge activity
|
00cc251 to
2886073
Compare
2886073 to
f24286f
Compare

What does this PR do?
Rewrites
get_available_memory()to walk the cgroup v2 ancestor chain from the process-specific path upward, returning the tightestmemory.maxlimit. The previous implementation only checked the cgroup root, which returns "max" when the container has its own cgroup namespace — causing lading to useu64::MAXinstead of the actual container memory limit.Motivation
In cgroup v2 environments where the container has its own cgroup namespace (common in Docker/Kubernetes),
/sys/fs/cgroup/memory.maxat the root reads "max" even though a real limit exists at the process-specific cgroup path. This caused lading to believe it had unlimited memory.Related issues
N/A
Additional Notes
ubuntu-latesttoubuntu-24.04to speed up CI times.get_available_memory_with) for deterministic unit testing of cgroup parsing logic.