Терминология

cgroup — это набор процессов, которые связаны с набором ограничений или параметров, определяемых через файловую систему cgroup.

subsystem — компонент ядра, который изменяет поведение процессов в cgroup-у. Реализованы различные подсистемы, они позволяют делать разные вещи, например ограничивать количество времени ЦП и память доступную для cgroup-ы, подсчитывать время ЦП, используемое группой и останавливать и возобновлять выполнение процессов в cgroup-е. Подсистемы иногда также называют контроллерами ресурсов (или просто, контроллерами).

Для контроллера cgroup-ы упорядочены в иерархию. Иерархия определяется посредством создания, удаления и переименования подкаталогов в файловой системе cgroup. На каждом уровне иерархии можно задать атрибуты (например, ограничения). Если атрибуты назначены, то ограничение, контроль и учёт, предоставляемый cgroup-ами, обычно, распространяется в иерархии по всем нижестоящим элементам. То есть, например, ограничение, заданное на cgroup на высшем уровне иерархии не может быть превышено в дочерних cgroup-ах.

Cgroups версии 1 и 2

The initial release of the cgroups implementation was in Linux 2.6.24. Over time, various cgroup controllers have been added to allow the management of various types of resources. However, the development of these controllers was largely uncoordinated, with the result that many inconsistencies arose between controllers and management of the cgroup hierarchies became rather complex. A longer description of these problems can be found in the kernel source file Documentation/admin-guide/cgroup-v2.rst (or Documentation/cgroup-v2.txt in Linux 4.17 and earlier).

Because of the problems with the initial cgroups implementation (cgroups version 1), starting in Linux 3.10, work began on a new, orthogonal implementation to remedy these problems. Initially marked experimental, and hidden behind the -o __DEVEL__sane_behavior mount option, the new version (cgroups version 2) was eventually made official with the release of Linux 4.5. Differences between the two versions are described in the text below. The file cgroup.sane_behavior, present in cgroups v1, is a relic of this mount option. The file always reports "0" and is only retained for backward compatibility.

Хотя cgroups v2 создавалась как замена cgroups v1, старая система всё ещё существует (и для обеспечения совместимости её не хотелось бы удалять). В настоящее время, в cgroups v2 реализованы не все контроллеры, доступные в cgroups v1. Эти две системы реализованы таким образом, что контроллеры v1 и v2 можно монтировать одновременно. То есть, например, можно не только использовать контроллеры, поддерживаемые версией 2, но и использовать контроллеры версии 1, которые пока не поддерживаются версией 2. Единственным ограничением является то, что один и тот же контроллер не может быть запущен одновременно в иерархии cgroups v1 и cgroups v2.

Задачи (нити) и процессы

В cgroups v1 процессы и задачи различаются. Процесс может состоять из нескольких задач (чаще всего называемых нитями, если смотреть из пользовательского пространства, и так они будут называться далее в этой справочной странице). В cgroups v1 возможно независимо управлять членством cgroup для нитей процесса.

В некоторых случаях способность cgroups v1 разделять нити по разным cgroups вызывает проблемы. Например, это не имеет смысла для контроллера memory, так как все нити процесса находятся в одном адресном пространстве. Из-за таких проблем способность независимого управления членством cgroup для нитей процесса была удалена в первой реализации cgroups v2, но позже восстановлена в более ограниченном виде (смотрите описание «режим нитей» ниже).

Монтирование контроллеров v1

Для использования cgroups требуется собрать ядро с параметром CONFIG_CGROUP. Также с каждым контроллером v1 связан параметр настройки, который должен быть задан, если нужно работать с этим контроллером.

Чтобы использовать контроллер a v1, его нужно смонтировать в файловую систему cgroup. Обычно для этого используют файловую систему tmpfs(5), смонтированную в /sys/fs/cgroup. Таким образом, можно смонтировать контроллер cpu следующим образом:

mount -t cgroup -o cpu none /sys/fs/cgroup/cpu

Можно смонтировать несколько контроллеров вместе в одной иерархии. Например, так контроллеры cpu и cpuacct одновременно монтируются в одной иерархии:

mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct

Для одновременно смонтированных контроллеров процесс находится в одной cgroup всех одновременно смонтированных контроллеров. Отдельно смонтированные контроллеры позволяют процессу находиться в cgroup /foo1 одного контроллера и в /foo2/foo3 другого.

Можно смонтировать все контроллеры v1 вместе в одной иерархии:

mount -t cgroup -o all cgroup /sys/fs/cgroup

(Параметр -o all можно опустить, так как по умолчанию монтируются все контроллеры, если ни один не указан явно)

It is not possible to mount the same controller against multiple cgroup hierarchies. For example, it is not possible to mount both the cpu and cpuacct controllers against one hierarchy, and to mount the cpu controller alone against another hierarchy. It is possible to create multiple mount with exactly the same set of comounted controllers. However, in this case all that results is multiple mount points providing a view of the same hierarchy.

Note that on many systems, the v1 controllers are automatically mounted under /sys/fs/cgroup; in particular, systemd(1) automatically creates such mounts.

Размонтирование контроллеров v1

Смонтированная файловая система cgroup может быть размонтирована с помощью команды umount(8) как показано в этом примере:

umount /sys/fs/cgroup/pids

But note well: a cgroup filesystem is unmounted only if it is not busy, that is, it has no child cgroups. If this is not the case, then the only effect of the umount(8) is to make the mount invisible. Thus, to ensure that the mount is really removed, one must first remove all child cgroups, which in turn can be done only after all member processes have been moved from those cgroups to the root cgroup.

Контроллеры cgroups версии 1

Все контроллеры cgroups версии 1 управляются параметрами настройки ядра (список далее). Также, включение свойства cgroups управляется параметром настройки ядра CONFIG_CGROUPS.

cpu (начиная с Linux 2.6.24; CONFIG_CGROUP_SCHED)

Cgroups can be guaranteed a minimum number of "CPU shares" when a system is busy. This does not limit a cgroup's CPU usage if the CPUs are not busy. For further information, see Documentation/scheduler/sched-design-CFS.rst (or Documentation/scheduler/sched-design-CFS.txt in Linux 5.2 and earlier).

In Linux 3.2, this controller was extended to provide CPU "bandwidth" control. If the kernel is configured with CONFIG_CFS_BANDWIDTH, then within each scheduling period (defined via a file in the cgroup directory), it is possible to define an upper limit on the CPU time allocated to the processes in a cgroup. This upper limit applies even if there is no other competition for the CPU. Further information can be found in the kernel source file Documentation/scheduler/sched-bwc.rst (or Documentation/scheduler/sched-bwc.txt in Linux 5.2 and earlier).

cpuacct (начиная с Linux 2.6.24; CONFIG_CGROUP_CPUACCT)

Включает учёт использования ЦП группами процессов.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/cpuacct.rst (or Documentation/cgroup-v1/cpuacct.txt in Linux 5.2 and earlier).

cpuset (начиная с Linux 2.6.24; CONFIG_CPUSETS)

Эту cgroup можно использовать для привязки процессов в cgroup к указанному набору ЦП и узлов NUMA.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/cpusets.rst (or Documentation/cgroup-v1/cpusets.txt in Linux 5.2 and earlier).

memory (начиная с Linux 2.6.25; CONFIG_MEMCG)

Контроллер памяти поддерживает учёт и ограничение памяти процесса, памяти ядра и подкачки, используемой cgroups.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/memory.rst (or Documentation/cgroup-v1/memory.txt in Linux 5.2 and earlier).

devices (начиная с Linux 2.6.26; CONFIG_CGROUP_DEVICE)

This supports controlling which processes may create (mknod) devices as well as open them for reading or writing. The policies may be specified as allow-lists and deny-lists. Hierarchy is enforced, so new rules must not violate existing rules for the target or ancestor cgroups.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/devices.rst (or Documentation/cgroup-v1/devices.txt in Linux 5.2 and earlier).

freezer (начиная с Linux 2.6.28; CONFIG_CGROUP_FREEZER)

freezer cgroup может приостанавливать и возобновлять работу всех процессов в cgroup. Заморозка cgroup /A также влияет на её потомков, например, процессы в /A/B тоже приостанавливаются.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst (or Documentation/cgroup-v1/freezer-subsystem.txt in Linux 5.2 and earlier).

net_cls (начиная с Linux 2.6.29; CONFIG_CGROUP_NET_CLASSID)

Помещает classid, задаваемые для cgroup, в сетевые пакеты, создаваемые cgroup. Эти classid затем можно использовать в правилах межсетевого экрана, а также для ограничения трафика с помощью tc(8). Применяется только к пакетам, выходящим из cgroup, и не применяется к входящему трафику cgroup.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/net_cls.rst (or Documentation/cgroup-v1/net_cls.txt in Linux 5.2 and earlier).

blkio (начиная с Linux 2.6.33; CONFIG_BLK_CGROUP)

blkio cgroup контролирует и ограничивает доступ к заданным блочным устройствам, применяет управление вводом-выводом посредством пропусков (throttling) и ограничения сверху листовых узлов и и промежуточных узлов в иерархии хранилища.

Доступно две стратегии. Первая: пропорционально взвешенное повременное разделение диска, реализованная посредством CFQ. Влияет на листовые узлы с помощью CFQ. Вторая: стратегия пропусков, которая задаётся верхним ограничением скорости обмена с устройством.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/blkio-controller.rst (or Documentation/cgroup-v1/blkio-controller.txt in Linux 5.2 and earlier).

perf_event (начиная с Linux 2.6.39; CONFIG_CGROUP_PERF)

Этот контроллер позволяет выполнять слежение perf за набором процессов, сгруппированных в cgroup.

Further information can be found in the kernel source files

net_prio (начиная с Linux 3.3; CONFIG_CGROUP_NET_PRIO)

Позволяет для cgroups задавать свой приоритет на каждый интерфейс.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/net_prio.rst (or Documentation/cgroup-v1/net_prio.txt in Linux 5.2 and earlier).

hugetlb (начиная с Linux 3.5; CONFIG_CGROUP_HUGETLB)

Поддерживает ограничение cgroups на использование огромных страниц.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/hugetlb.rst (or Documentation/cgroup-v1/hugetlb.txt in Linux 5.2 and earlier).

pids (начиная с Linux 4.3; CONFIG_CGROUP_PIDS)

Этот контроллер позволяет ограничивать количество процессов, которые могут быть созданы в cgroup (и её потомках).

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/pids.rst (or Documentation/cgroup-v1/pids.txt in Linux 5.2 and earlier).

rdma (начиная с Linux 4.11; CONFIG_CGROUP_RDMA)

Контроллер RDMA позволяет ограничивать использование ресурсов RDMA/IB определённой cgroup.

Further information can be found in the kernel source file Documentation/admin-guide/cgroup-v1/rdma.rst (or Documentation/cgroup-v1/rdma.txt in Linux 5.2 and earlier).

Создание cgroups и перемещение процессов

Первоначально, в файловой системе cgroup содержится только корневая cgroup, «/», которой принадлежат все процессы. Новая cgroup создаётся посредством создания каталога в файловой системе cgroup:

mkdir /sys/fs/cgroup/cpu/cg1

Данная команда создаёт новую пустую cgroup.

Помещение процесса в эту cgroup выполняется с помощью записи его PID в файл cgroup cgroup.procs:

echo $$ > /sys/fs/cgroup/cpu/cg1/cgroup.procs

В этот файл единовременно должен записываться только один PID.

Запись в файл cgroup.procs значения 0 приводит к помещению в соответствующую cgroup записывающего процесса.

При записи PID в cgroup.procs в новую cgroup одновременно перемещаются все нити процесса.

Внутри иерархии процесс может быть членом только одной cgroup. Запись PID процесса в файл cgroup.procs автоматически удаляет его из cgroup, в которой он числился до этого.

Для получения списка процессов, числящихся в cgroup, можно прочитать файл cgroup.procs. Возвращаемый список PID не обязательно упорядочен. Также PID могут повторяться (например, во время чтения списка PID может использоваться повторно).

В cgroups v1 отдельные нити могут перемещаться в другую cgroup посредством записи ID нити (т. е., ядерный ID нити, возвращаемый clone(2) и gettid(2)) в файл tasks из каталога cgroup. Этот файл можно прочитать, чтобы получить набор нитей, принадлежащих cgroup.

Удаление cgroups

Удаляемая cgroup не должна содержать дочерних cgroups и процессов (не зомби). Если это соблюдается, то можно просто удалить соответствующий каталог. Заметим, что файлы в каталоге cgroup невозможно и ненужно удалять.

Выпуск уведомлений cgroups v1

Для определения того, как ядро выполняет уведомления об опустевших cgroup, можно использовать два файла. Cgroup считается пустой, если не содержит дочерних cgroup и процессов.

Специальный файл в корневом каталоге каждой иерархии cgroup, release_agent, можно использовать для регистрации программы, которая будет вызываться всякий раз, когда cgroup в иерархии становится пустой. При вызове программы release_agent в единственной аргументе командной строки передаётся путь (относительно точки монтирования cgroup) только что опустевшей cgroup. Программа release_agent может удалить удалить каталог cgroup или, возможно, повторно добавить в него процесс.

По умолчанию файл release_agent пуст, то есть агент освобождения не вызывается.

Содержимое файла release_agent также можно задать в параметре монтирования при монтировании файловой системы cgroup:

mount -o release_agent=файл …

Будет ли программа release_agent вызываться для определённой ставшей пустой cgroup, задаётся значением файла notify_on_release в каталоге, соответствующем cgroup. Если этот файл содержит значение 0, то программа release_agent не вызывается. Если он содержит 1, то программа release_agent вызывается. По умолчанию в этом файле содержится 0 для корневой cgroup. В момент, когда создаётся новая cgroup, значение в этом файле наследуется из соответствующего файла родительской cgroup.

Именованные иерархии cgroup v1

В cgroups v1 возможно монтирование иерархии cgroup, у которой нет присоединённых контроллеров:

mount -t cgroup -o none,name=какое-то_имя none /some/mount/point

Можно смонтировать несколько экземпляров таких иерархий; каждая иерархия должна иметь уникальное имя. Единственной целью таких иерархий является слежение за процессами (смотрите описание о выдаче уведомлений ниже). В пример можно привести иерархию cgroup name=systemd, которая используется systemd(1) для слежения за службами и пользовательскими сеансами.

Начиная с Linux 5.0, параметром ядра cgroup_no_v1 (описан ниже) можно выключить иерархию cgroup v1 с определённым именем: cgroup_no_v1=named.

Унифицированная иерархия cgroups v2

В cgroups v1, способность монтировать различные контроллеры в разные иерархии предназначалась для повышения гибкости при разработки приложения. Однако на практике выяснилось, что гибкость не так полезна как ожидалось, и во многих случаях добавляет сложности. Поэтому в cgroups v2, все доступные контроллеры монтируются в одну иерархию. Доступные контроллеры монтируются автоматически, то есть не нужно (но можно) указывать контроллеры при монтировании файловой системы cgroup v2 с помощью команды вида:

mount -t cgroup2 none /mnt/cgroup2

Контроллер cgroup v2 доступен только, если он уже не смонтирован в иерархии cgroup v1. Или, иначе говоря, невозможно использовать тот же контроллер одновременно в иерархии v1 и унифицированной иерархии v2. Это означает, что сначала может потребоваться размонтировать контроллер v1 (как описано выше), чтобы он стал доступен в v2. Так как systemd(1) по умолчанию интенсивно использует некоторые контроллеры v1, в некоторых случаях проще загрузить систему с отключёнными контроллерами v1. Для этого укажите параметр cgroup_no_v1=список в командной строке загрузки ядра; в списке через запятую перечисляются имена отключаемых контроллеров или указывается слово all для выключения всех контроллеров v1 (этот вариант корректно отрабатывается systemd(1) и она начинает работать без указанных контроллеров).

Заметим, что во многих современных системах systemd(1) автоматически монтирует файловую систему cgroup2 в каталог /sys/fs/cgroup/unified при запуске системы.

Cgroups v2 mount options

The following options (mount -o) can be specified when mounting the group v2 filesystem:

nsdelegate (начиная с Linux 4.15)

Treat cgroup namespaces as delegation boundaries. For details, see below.

memory_localevents (since Linux 5.2)

The memory.events should show statistics only for the cgroup itself, and not for any descendant cgroups. This was the behavior before Linux 5.2. Starting in Linux 5.2, the default behavior is to include statistics for descendant cgroups in memory.events, and this mount option can be used to revert to the legacy behavior. This option is system wide and can be set on mount or modified through remount only from the initial mount namespace; it is silently ignored in noninitial namespaces.

Контроллеры cgroups v2

The following controllers, documented in the kernel source file Documentation/admin-guide/cgroup-v2.rst (or Documentation/cgroup-v2.txt in Linux 4.17 and earlier), are supported in cgroups version 2:

cpu (начиная с Linux 4.15)

Приемник контроллеров cpu и cpuacct версии 1.

cpuset (since Linux 5.0)

This is the successor of the version 1 cpuset controller.

freezer (since Linux 5.2)

This is the successor of the version 1 freezer controller.

hugetlb (since Linux 5.6)

This is the successor of the version 1 hugetlb controller.

io (начиная с Linux 4.5)

Приемник контроллера blkio версии 1.

memory (начиная с Linux 4.5)

Приемник контроллера memory версии 1.

perf_event (начиная с Linux 4.11)

Совпадает с контроллером perf_event версии 1.

pids (начиная с Linux 4.5)

Совпадает с контроллером pids версии 1.

rdma (начиная с Linux 4.11)

Совпадает с контроллером rdma версии 1.

There is no direct equivalent of the net_cls and net_prio controllers from cgroups version 1. Instead, support has been added to iptables(8) to allow eBPF filters that hook on cgroup v2 pathnames to make decisions about network traffic on a per-cgroup basis.

The v2 devices controller provides no interface files; instead, device control is gated by attaching an eBPF (BPF_CGROUP_DEVICE) program to a v2 cgroup.

Управление поддеревом cgroups v2

Каждая cgroup в иерархии v2 содержит следующие два файла:

cgroup.controllers

Доступный только для чтения файл со списком контроллеров, доступных в этой cgroup. Содержимое этого файла совпадает с содержимым файла cgroup.subtree_control в родительской cgroup.

cgroup.subtree_control

Список контроллеров, активных (включённых) в cgroup. Набор контроллеров в этом файле является поднабором cgroup.controllers этой cgroup. Изменение набора активных контроллеров выполняется записью строк в этот файл с именами контроллеров через пробел; перед именами указывается «+» (включить контроллер) или «-» (выключить контроллер), как в следующем примере:

echo '+pids -memory' > x/y/cgroup.subtree_control

Попытка включить контроллер, который отсутствует в cgroup.controllers, приводит к ошибке ENOENT при записи в файл cgroup.subtree_control.

Так как список контроллеров в cgroup.subtree_control является поднабором из cgroup.controllers, то контроллер, отключённый в иерархии cgroup, невозможно включить в поддереве ниже этой cgroup.

Файл cgroup cgroup.subtree_control определяет набор контроллеров, которые выполняются в дочерних cgroup. Когда контроллер (например pids), есть в файле cgroup.subtree_control родительской cgroup, то соответствующие файлы интерфейса контроллера (например pids.max) автоматически создаются в дочерних cgroup и могут использоваться для влияния на управление ресурсами в дочерних cgroup.

Cgroups v2 "no internal processes" rule

Cgroups v2 вводит так называемое правило «нет внутренним процессам». Грубо говоря, это правило означает, что за исключением корневой cgroup, процессы могут располагаться только в краевых узлах (cgroup, которая не содержит дочерних cgroup). Это позволяет не решать как делить ресурсы между процессами, которые являются членами cgroup A и процессами в дочерних cgroup-ах A.

Например, если существует cgroup /cg1/cg2, то процесс может располагаться в /cg1/cg2, но не в /cg1. Это решает проблему с неясностью в cgroups v1 в плане разделения ресурсов между процессами в /cg1 и её дочерних cgroup-ах. Рекомендуемый подход в cgroups v2 — создать подкаталог leaf для всех конечных cgroup, в котором будут содержаться только процессы и отсутствовать дочерние cgroup-ы. То есть процессы, которые раньше находились в /cg1 теперь должны помещаться в /cg1/leaf. Преимуществом этого является явное указание родства между процессами в /cg1/leaf и в других потомках /cg1.

The "no internal processes" rule is in fact more subtle than stated above. More precisely, the rule is that a (nonroot) cgroup can't both (1) have member processes, and (2) distribute resources into child cgroups—that is, have a nonempty cgroup.subtree_control file. Thus, it is possible for a cgroup to have both member processes and child cgroups, but before controllers can be enabled for that cgroup, the member processes must be moved out of the cgroup (e.g., perhaps into the child cgroups).

С добавлением в Linux 4.14 «режима нитей» (смотрите далее) для некоторых случаев применение правила «не внутренних процессов» было ослаблено.

Файл cgroup.events в cgroups v2

Each nonroot cgroup in the v2 hierarchy contains a read-only file, cgroup.events, whose contents are key-value pairs (delimited by newline characters, with the key and value separated by spaces) providing state information about the cgroup:

$ cat mygrp/cgroup.events
populated 1
frozen 0

The following keys may appear in this file:

populated

The value of this key is either 1, if this cgroup or any of its descendants has member processes, or otherwise 0.

frozen (since Linux 5.2)

The value of this key is 1 if this cgroup is currently frozen, or 0 if it is not.

The cgroup.events file can be monitored, in order to receive notification when the value of one of its keys changes. Such monitoring can be done using inotify(7), which notifies changes as IN_MODIFY events, or poll(2), which notifies changes by returning the POLLPRI and POLLERR bits in the revents field.

Cgroup v2 release notification

Cgroups v2 provides a new mechanism for obtaining notification when a cgroup becomes empty. The cgroups v1 release_agent and notify_on_release files are removed, and replaced by the populated key in the cgroup.events file. This key either has the value 0, meaning that the cgroup (and its descendants) contain no (nonzombie) member processes, or 1, meaning that the cgroup (or one of its descendants) contains member processes.

The cgroups v2 release-notification mechanism offers the following advantages over the cgroups v1 release_agent mechanism:

•

It allows for cheaper notification, since a single process can monitor multiple cgroup.events files (using the techniques described earlier). By contrast, the cgroups v1 mechanism requires the expense of creating a process for each notification.

•

Notification for different cgroup subhierarchies can be delegated to different processes. By contrast, the cgroups v1 mechanism allows only one release agent for an entire hierarchy.

Файл cgroup.stat в cgroups v2

Каждая cgroup в иерархии v2 содержит файл cgroup.stat, доступный только для чтения (появился в Linux 4.14), который состоит из строк с парами ключ-значение. В этом файле появляются следующие ключи:

nr_descendants

Общее количество видимых (т. е., живых) cgroups — потомков этой cgroup.

nr_dying_descendants

Общее количество прекративших работу cgroups — потомков этой cgroup. cgroups входит в состояния прекращения жизнедеятельности после удаления. Она остаётся в таком состоянии на неопределённых срок (зависит от системной нагрузки), хотя ресурсы освобождаются до уничтожения cgroup. Заметим, что существование несколькими cgroups в состоянии прекращения жизнедеятельности нормально и не указывает на проблему.

Процесс не может стать членом прекратившей работу cgroup, и такая cgroup не может опять заработать.

Ограничение на количество дочерних cgroups

Каждая cgroup в иерархии v2 содержит следующие файлы, которые можно использовать для просмотра и изменения количества дочерних cgroup в cgroup:

cgroup.max.depth (начиная с Linux 4.14)

Этим файлом задаётся ограничение глубины вложенности дочерних cgroup. Значение 0 означает запрет на создание дочерних cgroup. Попытка создать потомка, чья глубина вложенности превышает ограничение, завершается ошибкой (mkdir(2) завершается ошибкой EAGAIN).

Writing the string "max" to this file means that no limit is imposed. The default value in this file is "max".

cgroup.max.descendants (начиная с Linux 4.14)

Этим файлом задаётся ограничение на количество действующих дочерних cgroup, которое может иметь cgroup. Попытка создать больше потомков, чем разрешено, приводит к ошибке (mkdir(2) завершается ошибкой EAGAIN).

Writing the string "max" to this file means that no limit is imposed. The default value in this file is "max".

Делегирование cgroups v2: nsdelegate и пространство имён cgroup

Начиная с Linux 4.13 появился второй способ делегирования cgroup в иерархии cgroups v2. Этого можно достичь монтированием или перемонтированием файловой системы cgroup v2 с параметром монтирования nsdelegate. Например, если файловая система cgroup v2 уже смонтирована, то её можно перемонтировать с параметром nsdelegate следующим образом:

mount -t cgroup2 -o remount,nsdelegate \
                 none /sys/fs/cgroup/unified

Данный параметр монтирования заставляет пространства имён cgroup автоматически устанавливать границы делегирования. При этом на процессы внутри пространства имён cgroup накладываются следующие ограничения:

•

Запись в файлы интерфейса к контроллерам в корневом каталоге пространства имён завершаются ошибкой EPERM. Процессы внутри пространства имён cgroup по-прежнему могут писать в делегированные файлы корневого каталога пространства имён cgroup (такие как cgroup.procs и cgroup.subtree_control) и могут создавать новые иерархии в корневом каталоге.

•

Попытки переноса процессов за границу пространства имён пресекаются (с ошибкой ENOENT). Процессы внутри пространства имён cgroup по-прежнему могут (цель сдерживающих правил описана ниже) перемещать процессы между cgroup внутри иерархий корневого каталога.

Возможность определения пространств имён cgroup для границ делегирования делает пространства имён cgroup ещё более полезными. Чтобы понять почему, предположим, что у нас уже есть одна иерархия cgroup, которая была делегирована непривилегированному пользователю, cecilia, посредством старого способа делегирования, описанного выше. Также предположим, что cecilia тоже хочет делегировать одну иерархий из имеющихся в делегированной иерархии (например, делегированная иерархия может быть связана с непривилегированным контейнером, запущенным cecilia). Даже, если пространство имён cgroup namespace было передано, так как обе иерархии принадлежат непривилегированному пользователю cecilia, могут быть выполнены следующие неправомерные действия:

•

Процесс в нижележащей иерархии может изменять настройки контроллера ресурсов в корневом каталоге этой иерархии (предполагается, что данными настройками контроллера ресурсов управляют из родительской cgroup; процесс внутри дочерней cgroup не должен быть способен изменять их).

•

Процесс в нижележащей иерархии может перемещать процессы в и из нижележащей иерархии, если cgroup вышестоящей иерархии видима откуда-то ещё.

Использование параметра монтирования nsdelegate предотвращает обе эти возможности.

Параметр монтирования nsdelegate действует только, когда применяется к начальному пространству имён монтирования; для других пространств имён монтирования он игнорируется.

Замечание: в некоторых системах systemd(1) автоматически монтирует файловую систему cgroup v2. Чтобы попробовать работу с nsdelegate , может быть полезно загрузить ядро с следующими параметрами командной строки:

cgroup_no_v1=all systemd.legacy_systemd_cgroup_controller

Эти параметры заставляют ядро загружаться с выключенными контроллерами cgroups v1 (т. е., контроллеры доступны из иерархии v2) и указывают systemd(1) не монтировать и использовать иерархию cgroup v2, таким образом позволяя вручную смонтировать иерархию v2 с желаемыми параметрами после загрузки.

Сдерживающие правила делегирования cgroup

Некоторые сдерживающие правила делегирования обеспечивает то, что делегат может перемещать процессы в рамках делегированного поддерева, но не сможет перемещать процессы извне делегированного поддерева в поддерево и наоборот. Непривилегированный процесс (т. е., делегат) может записать PID «целевого» процесса в файл cgroup.procs только, если всё следующее верно:

•

Писатель имеет права на запись в файл cgroup.procs в группе назначения cgroup.

•

Писатель имеет права на запись в файл cgroup.procs в ближайшем общем предке для cgroups источника и назначения. Заметим, что в некоторых случаях, ближайшим общим предком может быть сама cgroup источника или назначения. Это требование не выполняется в иерархиях cgroups v1, в следствие чего сдерживание в v1 менее ограничительно, чем v2 (например, в cgroups v1 пользователь, которому принадлежат две разных делегированных подиерархий, может перемещать процесс между этими иерархиями).

•

Если файловая система cgroup v2 смонтирована с параметром nsdelegate, то писатель способен видеть cgroup источника и приёмника из своего пространства имён cgroup.

•

В cgroups v1: эффективный UID писателя (т. е., делегата) совпадает с реальным пользовательским ID или сохранённым set-user-ID процесса назначения. До Linux 4.11 это требование также применялось к cgroups v2 (это исторически сложившиеся требование, унаследовано от cgroups v1, которое позднее сочли ненужным, так как достаточно других сдерживающих правил cgroups v2).

Замечание: одним из следствий этих сдерживающих правил является то, что непривилегированный делегат не может поместить первый процесс в делегированное поддерево; вместо этого делегирующему необходимо поместить первый процесс (процесс, принадлежащей делегату) в делегированное поддерево.

Сравнение контроллеров домена и нитей

С добавлением режима нитей теперь в cgroups v2 различают два типа контроллеров ресурсов:

•

Контроллеры нитей: эти контроллеры поддерживают понитевое управление ресурсами и могут включаться в поддеревья нитей; в результате появляются соответствующие файлы интерфейса контроллера внутри cgroup в поддереве нитей. В Linux 4.19 имеются следующие контроллеры нитей: cpu, perf_event и pids.

•

Контроллеры домена: эти контроллеры поддерживают только попроцессное управление ресурсами. С точки зрения контроллера домена все нити процесса всегда находятся в одной группе. Контроллеры домена нельзя включить внутри поддерева нитей.

Создание поддерева нитей

Существует два способа создания поддерева нитей. Первый:

(1)

We write the string "threaded" to the cgroup.type file of a cgroup y/z that currently has the type domain. This has the following effects:

(2)

We write the string "threaded" to each of the domain invalid cgroups under y, in order to convert them to the type threaded. As a consequence of this step, all threads under the threaded root now have the type threaded and the threaded subtree is now fully usable. The requirement to write "threaded" to each of these cgroups is somewhat cumbersome, but allows for possible future extensions to the thread-mode model.

Второй способ создания поддерева нитей:

(1)

In an existing cgroup, z, that currently has the type domain, we (1.1) enable one or more threaded controllers and (1.2) make a process a member of z. (These two steps can be done in either order.) This has the following consequences:

(2)

As before, we make the threaded subtree usable by writing the string "threaded" to each of the domain invalid cgroups under z, in order to convert them to the type threaded.

Следствием одного из этих путей создания поддерева нитей является то, что cgroup корня нитей может быть родителем только cgroup с типом threaded (и domain invalid). cgroup корня нитей не может быть родителем cgroup с типом domain и cgroup с типом threaded не может быть на одном уровне с cgroup с типом domain.

Использование поддерева нитей

В поддереве нитей можно включать контроллеры нитей для каждой подгруппы, чей тип был изменён на threaded; после того, как это сделано, файлы интерфейса соответствующего контроллера появятся в дочерних cgroup.

Процесс можно перемещать в поддерево нитей посредством записи его PID в файл cgroup.procs одной из cgroup внутри дерева. В результате все нити процесса становятся членами соответствующей cgroup,а процесс — членом поддерева нитей. После этого нити процесса можно размещать по поддереву нитей посредством записи ID нитей (смотрите gettid(2)) в файлы cgroup.threads различных cgroup внутри поддерева. Все нити процесса должны быть расположены в одном поддереве нитей.

Как и при записи в cgroup.procs, при записи в файл cgroup.threads накладываются некоторые сдерживающие правила:

•

Писатель должен иметь права на запись в файл cgroup.threads целевой cgroup.

•

Писатель должен иметь права на запись в файл cgroup.procs в общем предке для cgroups источника и назначения (в некоторых случаях, общим предком может быть сама cgroup источника или назначения).

•

Целевая и cgroup назначения должны быть в одном поддереве нитей (попытка переместить нить вне поддерева нитей посредством записи ID этой нити в файл cgroup.threads другой cgroup с типом domain завершится ошибкой EOPNOTSUPP).

Файл cgroup.threads существует в каждой cgroup (включая cgroup c типом domain) и может быть прочитан для нахождения набора нитей, представленных в группе. Для набора ID нитей, получаемых при чтении этого файла, не гарантируется порядок и отсутствие повторов.

Файл cgroup.procs в корне нитей отражает PID всех процессов, являющихся членами поддерева нитей. Файлы cgroup.procs других cgroup в поддереве недоступны для чтения.

Доменные контроллеры невозможно включить в поддереве нитей; в cgroup ниже корня нитей отсутствуют интерфейсные файлы контроллера. С точки зрения доменного контроллера поддеревья нитей невидимы: многонитевые процессы внутри поддерева нитей видятся доменным контроллером как процесс, расположенный в cgroup корня нитей.

В поддереве нитей правило «нет внутренних процессов» не применяется: cgroup может иметь одновременно процессы-члены (или нить) и выполняемые контроллеры в дочерних cgroup.

Правила записи в cgroup.type и создание поддеревьев нитей

При записи в файл cgroup.type накладывается несколько правил:

•

Only the string "threaded" may be written. In other words, the only explicit transition that is possible is to convert a domain cgroup to type threaded.

•

The effect of writing "threaded" depends on the current value in cgroup.type, as follows:

•

Нельзя писать в файл cgroup.type, если тип родителя domain invalid. Иначе говоря, все cgroup поддерева нитей должны быть преобразованы в состояние threaded по нисходящей.

Также для создания поддерева нитей с корнем cgroup x требуется выполнить несколько условий:

•

Не должно быть процессов-членов в дочерних cgroup x (сама cgroup x может иметь процессы-члены).

•

Не должно быть включённых доменных контроллеров для x в файле cgroup.subtree_control.

If any of the above constraints is violated, then an attempt to write "threaded" to a cgroup.type file fails with the error ENOTSUP.

The "domain threaded" cgroup type

Согласно способам, описанным выше, тип cgroup можно измениться на domain threaded в следующих случаях:

•

The string "threaded" is written to a child cgroup.

•

Внутри cgroup включён контроллер нитей и процесс стал членом cgroup.

A domain threaded cgroup, x, can revert to the type domain if the above conditions no longer hold true—that is, if all threaded child cgroups of x are removed and either x no longer has threaded controllers enabled or no longer has member processes.

Когда cgroup x с типом domain threaded возвращается к типу domain:

•

Все потомки x с domain invalid, находящиеся не ниже уровня поддеревьев нитей, получают тип domain.

•

Корневым cgroup, находящимся ниже поддеревьев нитей возвращается тип domain threaded.

Исключения для корневой cgroup

The root cgroup of the v2 hierarchy is treated exceptionally: it can be the parent of both domain and threaded cgroups. If the string "threaded" is written to the cgroup.type file of one of the children of the root cgroup, then

•

Типом этой cgroup становится threaded.

•

Тип всех потомков этой cgroup, не являющихся частью уровня ниже поддеревьев нитей, изменяется на domain invalid.

Заметим, что в этом случае нет cgroup, чей тип стал domain threaded (в принципе, корневая cgroup может рассматриваться как корень нитей для cgroup, чей тип был изменён на threaded).

Данное исключение для корневой cgroup позволяет cgroup нитей, запускающей контроллер cpu, быть помещённой выше всех насколько возможно в иерархии, для того, чтобы минимизировать ущерб (маленький) от обхода иерархии cgroup.

The cgroups v2 "cpu" controller and realtime threads

As at Linux 4.19, the cgroups v2 cpu controller does not support control of realtime threads (specifically threads scheduled under any of the policies SCHED_FIFO, SCHED_RR, described SCHED_DEADLINE; see sched(7)). Therefore, the cpu controller can be enabled in the root cgroup only if all realtime threads are in the root cgroup. (If there are realtime threads in nonroot cgroups, then a write(2) of the string "+cpu" to the cgroup.subtree_control file fails with the error EINVAL.)

В некоторых системах systemd(1) помещает определённые нити реального времени в некорневую cgroups иерархии v2. В таких системах такие нити должны помещаться раньше в корневую cgroup, до включения контроллера cpu.

Файлы в /proc

/proc/cgroups (начиная с Linux 2.6.24)

В этом файле содержится информация о контроллерах, с которыми было собрано ядро. Пример содержимого файла (переформатирован для читабельности):

#subsys_name    hierarchy      num_cgroups    enabled
cpuset          4              1              1
cpu             8              1              1
cpuacct         8              1              1
blkio           6              1              1
memory          3              1              1
devices         10             84             1
freezer         7              1              1
net_cls         9              1              1
perf_event      5              1              1
net_prio        9              1              1
hugetlb         0              1              0
pids            2              1              1

Поля файла, слева направо:

/proc/pid/cgroup (начиная с Linux 2.6.24)

Этот файл описывает управляемые группы, которым принадлежит процесс с соответствующим PID. Отображаемая информация отличается для иерархий cgroups версии 1 и 2.

Для каждой иерархии cgroup, членом которой является процесс, существует одна запись, состоящая из трёх полей через двоеточие:

ID иерархии:список контроллеров:путь cgroup

Пример:

5:cpuacct,cpu,cpuset:/daemons

Поля, разделяемые двоеточием, слева направо:

Файлы /sys/kernel/cgroup

/sys/kernel/cgroup/delegate (начиная с Linux 4.15)

Этот файл экспортирует список файлов cgroups v2 (один на строку), которые можно делегировать (т. е., у которых можно изменить владельца на пользовательских ID делегата). В будущем, наборов доступных для делегирования файлов может измениться или вырасти, а этот файл предоставляет способ, которым ядро информирует приложения пользовательского пространства о необходимых для делегирования файлах. В Linux 4.15 в этом файле можно увидеть следующее:

$ cat /sys/kernel/cgroup/delegate
cgroup.procs
cgroup.subtree_control
cgroup.threads

/sys/kernel/cgroup/features (начиная с Linux 4.15)

Со временем набор возможностей cgroups v2, предоставляемых ядром, может измениться или вырасти, или некоторые возможности по умолчанию могут быть отключены. Этот файл предоставляет способ, которым приложения пользовательского пространства могут узнать о том, какие возможности поддерживает работающее ядро и какие из них включены. Возможности перечисляются по одной на строку:

$ cat /sys/kernel/cgroup/features
nsdelegate
memory_localevents

В этом файле может появляться следующее: