diff options
author | Chris Down <chris@chrisdown.name> | 2018-12-03 15:38:06 +0100 |
---|---|---|
committer | Chris Down <chris@chrisdown.name> | 2018-12-03 16:40:31 +0100 |
commit | c72703e26d21cb4994f21ae50c4e18675b02ded3 (patch) | |
tree | c2f6cf0b7772548594323b2c98aa6bea387b303e /man/systemd.resource-control.xml | |
parent | cgroup: Traverse leaves to realised cgroup to release controllers (diff) | |
download | systemd-c72703e26d21cb4994f21ae50c4e18675b02ded3.tar.xz systemd-c72703e26d21cb4994f21ae50c4e18675b02ded3.zip |
cgroup: Add DisableControllers= directive to disable controller in subtree
Some controllers (like the CPU controller) have a performance cost that
is non-trivial on certain workloads. While this can be mitigated and
improved to an extent, there will for some controllers always be some
overheads associated with the benefits gained from the controller.
Inside Facebook, the fix applied has been to disable the CPU controller
forcibly with `cgroup_disable=cpu` on the kernel command line.
This presents a problem: to disable or reenable the controller, a reboot
is required, but this is quite cumbersome and slow to do for many
thousands of machines, especially machines where disabling/enabling a
stateful service on a machine is a matter of several minutes.
Currently systemd provides some configuration knobs for these in the
form of `[Default]CPUAccounting`, `[Default]MemoryAccounting`, and the
like. The limitation of these is that Default*Accounting is overrideable
by individual services, of which any one could decide to reenable a
controller within the hierarchy at any point just by using a controller
feature implicitly (eg. `CPUWeight`), even if the use of that CPU
feature could just be opportunistic. Since many services are provided by
the distribution, or by upstream teams at a particular organisation,
it's not a sustainable solution to simply try to find and remove
offending directives from these units.
This commit presents a more direct solution -- a DisableControllers=
directive that forcibly disallows a controller from being enabled within
a subtree.
Diffstat (limited to 'man/systemd.resource-control.xml')
-rw-r--r-- | man/systemd.resource-control.xml | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml index 4e282dad3d..aa7d9bcd59 100644 --- a/man/systemd.resource-control.xml +++ b/man/systemd.resource-control.xml @@ -736,6 +736,27 @@ </listitem> </varlistentry> + <varlistentry> + <term><varname>DisableControllers=</varname></term> + + <listitem> + <para>Disables controllers from being enabled for a unit's children. If a controller listed is already in use + in its subtree, the controller will be removed from the subtree. This can be used to avoid child units being + able to implicitly or explicitly enable a controller. Defaults to not disabling any controllers.</para> + + <para>It may not be possible to successfully disable a controller if the unit or any child of the unit in + question delegates controllers to its children, as any delegated subtree of the cgroup hierarchy is unmanaged + by systemd.</para> + + <para>Multiple controllers may be specified, separated by spaces. You may also pass + <varname>DisableControllers=</varname> multiple times, in which case each new instance adds another controller + to disable. Passing <varname>DisableControllers=</varname> by itself with no controller name present resets + the disabled controller list.</para> + + <para>Valid controllers are <option>cpu</option>, <option>cpuacct</option>, <option>io</option>, + <option>blkio</option>, <option>memory</option>, <option>devices</option>, and <option>pids</option>.</para> + </listitem> + </varlistentry> </variablelist> </refsect1> |