Control Groups

Line 4:

According to [https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ systemd's documentation], on a machine making use of systemd 205+ as its PID 1, the only legal way to interact with cgroupsv2 is through systemd's APIs (as cgroupsv2 is intended to be a "single-writer" facility). However, systemd exposes only a subset of the full cgroupsv2 functionality. Important cgroupv1 concepts like cpusets and freezer are not currently implemented. One must directly mess with the cgroupsv2 hierarchy to use this functionality, despite systemd's warnings. It tends to work out in the end.

==CPUsets with cgroupsv2==

* Ensure that the <tt>cgroups2</tt> filesystem is mounted:

<pre>root@schwarzgerat:/sys/fs/cgroup# mount | grep cgroup2

cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)

root@schwarzgerat:/sys/fs/cgroup# </pre>

* Ensure that <tt>cpuset</tt> is in <tt>/sys/fs/cgroup/cgroup.controllers</tt>:

<pre>root@schwarzgerat:/sys/fs/cgroup# cat cgroup.controllers

cpuset cpu io memory pids rdma

root@schwarzgerat:/sys/fs/cgroup# </pre>

If it's absent, you're either missing the necessary kernel support, or you have a cgroupv1 implementation mounted.

* Enable the controller in the toplevel:

<pre>root@schwarzgerat:/sys/fs/cgroup# cat cgroup.subtree_control

cpu memory pids

root@schwarzgerat:/sys/fs/cgroup# echo "+cpuset" > cgroup.subtree_control

root@schwarzgerat:/sys/fs/cgroup# cat cgroup.subtree_control

cpuset cpu memory pids

root@schwarzgerat:/sys/fs/cgroup# </pre>

* All subdirectories of your <tt>cgroup2</tt> filesystem will now have cpuset entries ala:

<pre>./user.slice/cpuset.cpus.partition

./user.slice/cpuset.cpus.effective

./user.slice/cpuset.mems

./user.slice/cpuset.mems.effective

./user.slice/cpuset.cpus</pre>

Control Groups: Difference between revisions

Dank (talk | contribs)

@@ Line 4: / Line 4: @@
 According to [https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ systemd's documentation], on a machine making use of systemd 205+ as its PID 1, the only legal way to interact with cgroupsv2 is through systemd's APIs (as cgroupsv2 is intended to be a "single-writer" facility). However, systemd exposes only a subset of the full cgroupsv2 functionality. Important cgroupv1 concepts like cpusets and freezer are not currently implemented. One must directly mess with the cgroupsv2 hierarchy to use this functionality, despite systemd's warnings. It tends to work out in the end.
+==CPUsets with cgroupsv2==
+* Ensure that the <tt>cgroups2</tt> filesystem is mounted:
+<pre>root@schwarzgerat:/sys/fs/cgroup# mount | grep cgroup2
+cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
+root@schwarzgerat:/sys/fs/cgroup# </pre>
+* Ensure that <tt>cpuset</tt> is in <tt>/sys/fs/cgroup/cgroup.controllers</tt>:
+<pre>root@schwarzgerat:/sys/fs/cgroup# cat cgroup.controllers
+cpuset cpu io memory pids rdma
+root@schwarzgerat:/sys/fs/cgroup# </pre>
+If it's absent, you're either missing the necessary kernel support, or you have a cgroupv1 implementation mounted.
+* Enable the controller in the toplevel:
+<pre>root@schwarzgerat:/sys/fs/cgroup# cat cgroup.subtree_control
+cpu memory pids
+root@schwarzgerat:/sys/fs/cgroup# echo "+cpuset" > cgroup.subtree_control
+root@schwarzgerat:/sys/fs/cgroup# cat cgroup.subtree_control
+cpuset cpu memory pids
+root@schwarzgerat:/sys/fs/cgroup# </pre>
+* All subdirectories of your <tt>cgroup2</tt> filesystem will now have cpuset entries ala:
+<pre>./user.slice/cpuset.cpus.partition
+./user.slice/cpuset.cpus.effective
+./user.slice/cpuset.mems
+./user.slice/cpuset.mems.effective
+./user.slice/cpuset.cpus</pre>