About kernel control groups

For a good overview of cgroups feature of the Linux kernel, check the Description and Control Groups Version 1 sections in the cgroups manual page. For more detailed information, see the legacy v1 kernel cgroups documentation and the current v2 kernel cgroups documentation.

Cgexec and systemd

On legacy v1 machines all StorPool services (see StorPool services) are started via the cgexec utility. It runs the service and accounts its resources in the given-by-parameters cgroups. For example, cgexec ./test -g cpuset:cpuset_cg -g memory:memory_cg will run the test binary. It would limit its cpuset resources by the limitations defined in the cpuset_cg cgroup, and its memory resources by the limitations defined in the memory_cg cgroup.

On new v2 machines, systemd will handle this resource control automatically.

Slices

On legacy v1 hierarchies it is a common practice to create cgroups with the same names under different controllers. This mimics the v2 unified hierarchy. Take, for example, the cpuset and memory controllers. If one creates a test cgroup in the memory controller, and also a test cgroup in the cpuset controller, this can be considered a slice. A more appropriate name for the two cgroups would be test.slice.

Defining slices makes it easier to keep track and impose limitations on resources used by a process or a group of processes. If you think of it as ‘the process runs in the test.slice’ that implies both cpuset restrictions from cpuset:test.slice and memory restrictions from memory:test.slice.

Nodes that run virtual guests have a machine.slice where all the virtual machines run, and system.slice where the system processes run. There are system and user slices for system and user processes that are managed by systemd.

On v2 machines, slice monitoring can be done via systemd native tools like systemd-cgls.