Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cgroupsv2 support #699

Open
dzuelke opened this issue Feb 20, 2024 · 0 comments · May be fixed by #732
Open

cgroupsv2 support #699

dzuelke opened this issue Feb 20, 2024 · 0 comments · May be fixed by #732

Comments

@dzuelke
Copy link
Contributor

dzuelke commented Feb 20, 2024

The buildpack currently reads available RAM from a hard-coded location: /sys/fs/cgroup/memory/memory.limit_in_bytes.

This is a cgroups v1 path; cgroups v2 use a set of different soft and hard limits exposed via /sys/fs/cgroup/mem.{min,low,high,max}.

For both v1 and v2, groups can be arranged hierarchically, so it's actually necessary to determine the group that applies to the currently running process by parsing the cgroup table for the current process in /proc.

For cgroups v1, an entry may exist for a particular controller, e.g. "memory". For v2, only a single unified hierarchy exists.

For cgroups v2, all leaf nodes always expose all effective limits for active controllers, meaning no traversal up the tree is necessary to determine a limit. For v1, such path traversal must be performed, as a child group may inherit a limit from its parent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant