CGroup v1 detection #1329
CGroup v1 detection #1329
Conversation
talbii
force-pushed
the
cgroup-v1-detection
branch
from
88c3d5d to
79b3366
Compare
We can split the parsing part to a unit-testable function and copy paste output samples of |
|
I actually think that testing this on a V1 docker is something we should do before committing this :) Not necessarily in a pytest / integration test, but at least manually. |
|
Sure, it's possible to test the parsing. Is this needed? About the actual detection: yes, I did test it on both v1 and v2 (with v1 being inside a VM). All seemed well. I guess it would be possible to unit test as a whole (creating Docker image, and running Dragonfly inside to it and checking limits, etc.), but this seems like overkill. |
|
I agree that it's an over kill (and not a unit test, more of an end to end test :). |
talbii
force-pushed
the
cgroup-v1-detection
branch
from
79b3366 to
ba92c9b
Compare
talbii
force-pushed
the
cgroup-v1-detection
branch
from
32c0d61 to
a0a86dd
Compare
|
Welp... not really sure what to do here. The test |
|
I don't even see the output for |
talbii
force-pushed
the
cgroup-v1-detection
branch
from
55577bd to
249468d
Compare
romange
force-pushed
the
cgroup-v1-detection
branch
from
249468d to
6750606
Compare
For future reference: testing. In order to test this feature (both for v1 and v2). To do this, create a cgroup and move Dragonfly into it before running. One way to do this is using a script, like: cat; ./dragonfly --logtostderr Enabling v1 (by default, you should have v2): Edit `/etc/default/grub`, and look for `GRUB_CMDLINE_LINUX_DEFAULT`. Append to it `systemd.unified_cgroup_hierarchy=0`, update GRUB using `sudo updat-grub`, and reboot. In v1, create a group `mycgroup` and add PID 1234 to it: ``` sudo mkdir -p /sys/fs/cgroup/memory/mycgroup sudo bash -c "echo 8589934592 > /sys/fs/cgroup/memory/mycgroup/memory.limit_in_bytes" # set mem limit to 8G sudo bash -c "echo 1234 > /sys/fs/cgroup/memory/mycgroup/tasks" # assign PID 1234 to this cgroup ``` In v2: ``` sudo mkdir -p /sys/fs/cgroup/mycgroup sudo bash -c "echo 8589934592 > /sys/fs/cgroup/mycgroup/memory.max" # set mem limit to 8G sudo bash -c "echo 1234 > /sys/fs/cgroup/mycgroup/cgroup.procs" # assign PID 1234 to this cgroup ``` then test by (using script example from before): ``` $ ./run.sh # contains: cat; ./dragonfly --logtostderr [1] 1234 [1] + 1234 suspended (tty input) ./run.sh fg ^D <look for Dragonfly memory limit> ``` Signed-off-by: talbii <[email protected]>
talbii
force-pushed
the
cgroup-v1-detection
branch
from
6750606 to
b393884
Compare
Add support for cgroup v1 limit checking For future reference: testing. In order to test this feature (both for v1 and v2). To do this, create a cgroup and move Dragonfly into it before running. One way to do this is using a script, like: cat; ./dragonfly --logtostderr Enabling v1 (by default, you should have v2): Edit `/etc/default/grub`, and look for `GRUB_CMDLINE_LINUX_DEFAULT`. Append to it `systemd.unified_cgroup_hierarchy=0`, update GRUB using `sudo updat-grub`, and reboot. In v1, create a group `mycgroup` and add PID 1234 to it: ``` sudo mkdir -p /sys/fs/cgroup/memory/mycgroup sudo bash -c "echo 8589934592 > /sys/fs/cgroup/memory/mycgroup/memory.limit_in_bytes" # set mem limit to 8G sudo bash -c "echo 1234 > /sys/fs/cgroup/memory/mycgroup/tasks" # assign PID 1234 to this cgroup ``` In v2: ``` sudo mkdir -p /sys/fs/cgroup/mycgroup sudo bash -c "echo 8589934592 > /sys/fs/cgroup/mycgroup/memory.max" # set mem limit to 8G sudo bash -c "echo 1234 > /sys/fs/cgroup/mycgroup/cgroup.procs" # assign PID 1234 to this cgroup ``` then test by (using script example from before): ``` $ ./run.sh # contains: cat; ./dragonfly --logtostderr [1] 1234 [1] + 1234 suspended (tty input) ./run.sh fg ^D <look for Dragonfly memory limit> ``` Signed-off-by: talbii <[email protected]>
Following some community interaction, this PR adds detection for cgroup v1 as well, where previously there was only v2 support.