Hoping someone can help advise with this issue.
When using systemd.unified_cgroup_hierarchy=0, there is no issue and cpuset works perfectly, but when using systemd.unified_cgroup_hierarchy=1, I get the following error:
level=error msg="balance: Unable to set cpuset" err="setting cgroup item for the container failed"
name=(instance) value="0,1,2,3"
I am not an expert with cgroups, so I don’t really know where to start. Any idea, what I could look into which could be causing this?
That’s only one of the dynamic re-balancing that appears to have failed, can you check what the CPU count in /proc/cpuinfo looks like in the container?
On both the host and inside the container, /proc/cpuinfo shows processors 0,1,2, and 3. Actually, the contents of /proc/cpuinfo are exactly the same on host and in container.
If I try to constrain it to 2 of 4 cpus, I just get the similar error:
time=“2024-04-25T10:21:09Z” level=error msg=“balance: Unable to set cpuset” err=“setting cgroup item for the container failed” name=alpinetest value=“0,1”
And all four cpus are used when running stress-ng to check.
As mentioned before, if I use systemd.unified_cgroup_hierarchy=0 kernel parameter, everything functions as expected, and stress-ng can only stress two cpus.
Anything else I can check?
Does the limit correctly apply on container restart?
There is a bit of weirdness with how cpuset restrictions get propagated down the cgroup tree, so the live changes to limits.cpu can occasionally hit a condition where they can’t be properly applied, but they should be fine after a container restart when that happens.