Support cgroups v1 and v2 for memory and CPU limits #732
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
schneems
reviewed
Jun 20, 2024
dzuelke
force-pushed
the
cgroupsv2
branch
4 times, most recently
from
6a71104 to
638bc92
Compare
Covers Docker in various permutations, as well as Heroku's past, present, and possible future behavior on CR and PS.
Main convenience function to use is 'cgroup_util_read_cgroup_memory_limit'. It will determine the presence of v1 or v2 controllers, traverse the hierarchy upwards until the mount root for v1, and, for v2, prefer memory.high over memory.max, by default falling back to memory.low. It will reject read limits that exceed a given maximum value, or 'MemFree' from 'free' as an alternative. For testing purposes, a location other than '/proc' can be provided for determining base cgroup mount, controller, and process membership information; similarly, a prefix can be supplied that will be prepended to any discovered cgroup hierarchy paths. GUS-W-16050052
Not as part of integration tests, but against Ubuntu 20/22/24 to cover any potential differences in used programs (e.g. 'free' only got '-L' fairly recently) or Bash behavior
It applies cgroup cpuset limits, but it's GNU coreutils only, so we have to fall back to getconf. Also ensure pipefail mode in the command substitution to catch all error cases.
…r cgroupsv2 Drop the -L option, it's better to have one good default behavior.
…/mountinfo as input to have a _contents suffix for clarity
…f -s and -p options
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The boot scripts now try to find group membership, controller, and mount info from
procfs, then read a suitable value:memory.limit_in_bytesfor v1memory.highfor v2 (the recommended way of setting limits)memory.max(e.g. Docker's-m)memory.low(e.g. Docker's--memory-reservation)memory.minThe routines that handle this are in
bin/util/cgroups.sh. They guard against silly values (such as Docker'smemory.limit_in_bytesat9223372036854771712on unlimited containers, that would be about 8 Exbibytes) and have options for overriding procfs and cgroupfs locations for testing, as well as a verbose mode. Primary "API" is thecgroup_util_read_cgroup_memory_limitfunction.If nothing is found, the boot scripts try falling back to plainly reading
/sys/fs/cgroup/memory/memory.limit_in_bytesdirectly, as before, using thecgroup_util_read_cgroup_memory_limit_with_fallbackfunction, which wrapscgroup_util_read_cgroup_memory_limit.Tests cover
set -eandset -uenvironments, as well as regular and verbose mode of the functions, in all possible permutations.Closes #699
GUS-W-16050052
GUS-W-16050059
Also now uses
nprocto get the number of cores, falling back togetconffor e.g. BSD systems (the boot scripts can be used on their own).For easier review, the test fixtures are in a separate commit.