On Thu, Apr 04, 2024 at 06:36:56AM +0200, Petr Malat <oss@xxxxxxxxx> wrote:
> So there is no point in creating B and one could use A directly.
There indeed isn't in this example.
Consider siblings A/B and A/C. B would have configured cpus (and
possibly be a partition root) while C is generally uninterested in
cpuset so would not be configured. (Setup like this is encountered more
easily on unified hierarchy where the tree is already organized without
cpuset considerations.)
If B took all A's CPUs, it would be an invalid partition, otherwise C
would use the remaining CPUs implicitly.
Documentation/admin-guide/cgroup-v2.rst already tries to describe
something like that:
An empty value indicates that the cgroup is using the same
setting as the nearest cgroup ancestor with a non-empty
"cpuset.cpus" or all the available CPUs if none is found.
But it doesn't work like that (kernel 6.7.9):
# cd /sys/fs/cgroup
# echo +cpuset >cgroup.subtree_control
# cat init.scope/cpuset.cpus
(empty is possible)
# cat init.scope/cpuset.cpus.effective
0-7
# echo 3 >init.scope/cpuset.cpus
# cat init.scope/cpuset.cpus.effective
3
echo "" >init.scope/cpuset.cpus
# cat init.scope/cpuset.cpus
3 (I'd expect empty again)
IOW, cpuset cgroup can have empty cpuset.cpus when it's freshly created
but it seems it cannot be reset back to such an indifferent state.
(To match it to the previous example A/C==init.scope, A/B would be some
foo.service (under -.slice) that requires configured cpuset.)
Michal
Attachment:
signature.asc
Description: PGP signature
