Check out my first novel, midnight's simulacra!
Control Groups: Difference between revisions
(Created page with "aka cgroupsv2 aka unified cgroups. Control Groups v2 were unveiled in Linux 4.5 as a means of controlling resource allocation across groups of tasks. Unlike the previous implementation of control groups (introduced in Linux 2.6.24), these cgroups would be under a single hierarchy, usually mounted with a <tt>cgroup2</tt>-type virtual filesystem at <tt>/sys/fs/cgroup</tt>. systemd makes fundamental use of cgroups (and indeed, last I checked it couldn't run without them...") |
No edit summary |
||
| Line 1: | Line 1: | ||
aka cgroupsv2 aka unified cgroups. Control Groups v2 were unveiled in Linux 4.5 as a means of controlling resource allocation across groups of tasks. Unlike the previous implementation of control groups (introduced in Linux 2.6.24), these cgroups would be under a single hierarchy, usually mounted with a <tt>cgroup2</tt>-type virtual filesystem at <tt>/sys/fs/cgroup</tt>. [[systemd]] makes fundamental use of cgroups (and indeed, last I checked it couldn't run without them) -- the systemd concept of a [https://www.freedesktop.org/software/systemd/man/systemd.slice.html slice] corresponds to a new cgroup node. I am unaware of anything useful that can be done with cgroupsv1 that can't be accomplished in cgroupsv2. | aka cgroupsv2 aka unified cgroups. Control Groups v2 were unveiled in Linux 4.5 as a means of controlling resource allocation across groups of tasks. Unlike the previous implementation of control groups (introduced in Linux 2.6.24), these cgroups would be under a single hierarchy, usually mounted with a <tt>cgroup2</tt>-type virtual filesystem at <tt>/sys/fs/cgroup</tt>. [[systemd]] makes fundamental use of cgroups (and indeed, last I checked it couldn't run without them) -- the systemd concept of a [https://www.freedesktop.org/software/systemd/man/systemd.slice.html slice] corresponds to a new cgroup node. I am unaware of anything useful that can be done with cgroupsv1 that can't be accomplished in cgroupsv2. | ||
A great deal of cgroup-related documentation refers to cgroupsv1, especially since it can more or less be run alongside cgroupsv2. Pretty much all information about [[ | A great deal of cgroup-related documentation refers to cgroupsv1, especially since it can more or less be run alongside cgroupsv2. Pretty much all information about [[Cpuset|cpusets]] (including anything referring to <tt>/dev/cpuset</tt> or libcpuset) is referring to the obsolete cpuset controller based on cgroupsv1. The [https://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups/ "PaxControlGroups"] document is cgroupsv1. | ||
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. | 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. | ||
Revision as of 07:50, 12 January 2023
aka cgroupsv2 aka unified cgroups. Control Groups v2 were unveiled in Linux 4.5 as a means of controlling resource allocation across groups of tasks. Unlike the previous implementation of control groups (introduced in Linux 2.6.24), these cgroups would be under a single hierarchy, usually mounted with a cgroup2-type virtual filesystem at /sys/fs/cgroup. systemd makes fundamental use of cgroups (and indeed, last I checked it couldn't run without them) -- the systemd concept of a slice corresponds to a new cgroup node. I am unaware of anything useful that can be done with cgroupsv1 that can't be accomplished in cgroupsv2.
A great deal of cgroup-related documentation refers to cgroupsv1, especially since it can more or less be run alongside cgroupsv2. Pretty much all information about cpusets (including anything referring to /dev/cpuset or libcpuset) is referring to the obsolete cpuset controller based on cgroupsv1. The "PaxControlGroups" document is cgroupsv1.
According to 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.
