cgroups

View documentation for cgclassify

$ tldr cgclassify

$ tldr cgcreate

$ tldr cgexec

The most common way to directly execute a command within a specified cgroup
using the libcgroup-tools is via cgexec:
cgexec [options] group_path command [arguments...]

group_path
    The path to the cgroup directory where the command will be executed (e.g., cpu:/user.slice/mygroup).

command
    The executable command to run within the specified cgroup.

arguments...
    Any arguments to be passed to the command.

-g <controllers:path>
    (cgexec/cgclassify) Specify the cgroup(s) for the process.
Multiple controllers and paths can be specified (e.g., cpu,memory:/mygroup).

-l
    (cgget/cgset) List parameters or cgroups.

--sticky
    (cgexec) Keep the process in the cgroup even if it forks or execs,
ensuring all its children inherit the cgroup assignment.

-h, --help
    Display help information for the specific command.

cgroups (control groups) is a powerful
Linux kernel feature that organizes processes hierarchically
into groups for resource management. It allows administrators to
distribute, account for, and isolate system resources such as CPU,
memory, network I/O, and block I/O among groups of processes.
This enables finer control over resource allocation, ensuring
that no single application or user can monopolize system resources
and impact overall system stability or performance.

It's important to note that 'cgroups' is not a single command
in itself, but rather a kernel mechanism. User-space interaction
with cgroups is primarily achieved through:
1. libcgroup-tools: A suite of commands like cgcreate,
cgexec, cgclassify, cgget, and cgset,
which allow direct manipulation of cgroup hierarchies and
assignment of processes.
2. systemd: On modern Linux distributions, systemd
integrates deeply with cgroups, managing services and user sessions
within cgroup hierarchies (e.g., via .slice, .scope, and
.service units). This is often the preferred method
for system-wide cgroup management.
3. cgroupfs: Direct interaction with the /sys/fs/cgroup
pseudo-filesystem, which exposes the cgroup hierarchy and
control files.

1. Kernel Feature, Not a Single Command: 'cgroups' refers to
a kernel mechanism, not a single executable. Interaction is through
a suite of tools or systemd.
2. Requires Root Privileges: Most cgroup operations, especially
creating or modifying cgroups, require root privileges.
3. Cgroupfs Mount: The cgroupfs pseudo-filesystem must be
mounted (typically at /sys/fs/cgroup) for cgroup operations.
4. Cgroup v1 vs. v2: Linux kernels support two versions of cgroups.
v1 allows individual controllers to be mounted separately, while v2
provides a unified hierarchy. Tools and behaviors can differ.
5. systemd Integration: On modern systems, systemd largely
manages cgroups, sometimes making direct use of libcgroup-tools
less common or even conflicting if not handled carefully.

Cgroups use various 'subsystems' (or controllers) to manage
different types of resources. Common subsystems include:
cpu: Controls CPU access.
memory: Limits memory usage.
blkio: Controls block I/O access.
cpuset: Assigns processes to specific CPUs and memory nodes.
net_cls: Tags network packets for QoS.
pids: Limits the number of processes/threads a cgroup can create.
freezer: Suspends or resumes processes within a cgroup.

Cgroups are organized in a tree-like hierarchy.
A child cgroup can further subdivide the resources allocated to
its parent. This allows for granular resource control,
for example, dedicating a percentage of CPU to a user, and then
subdividing that percentage among their running applications.

Cgroup v1: Allows different controllers to be mounted
on separate hierarchies. This can lead to complexities and
inconsistencies when managing multiple resources.
Cgroup v2: Introduces a unified hierarchy where all
controllers are managed within a single, consistent tree structure.
It aims to simplify management and provide better resource isolation
and fairness. Modern Linux distributions are moving towards v2.

The cgroups feature was initially developed by Google engineers
Paul Menage and Rohit Seth, and was first merged into the Linux kernel
in version 2.6.24 in January 2008. It was originally named 'process containers'
but was later renamed to 'control groups' (cgroups) to avoid confusion
with other containerization technologies.

Initially, cgroups v1 was developed with individual hierarchies for each
subsystem. Due to design limitations and complexities, a major redesign
resulted in cgroups v2, which began merging into the kernel around version 3.10
and became the default in many recent distributions.
The user-space libcgroup-tools package provides the command-line utilities
to interact with this kernel feature.

cgroup(7), cgcreate(1), cgexec(1), cgclassify(1), cgget(1), cgset(1), lscgroup(1), lssubsys(1), systemd.resource-control(5), systemd-cgls(1)