summaryrefslogtreecommitdiffstats
path: root/man/systemd.resource-control.xml
diff options
context:
space:
mode:
authorChris Down <chris@chrisdown.name>2018-12-03 15:38:06 +0100
committerChris Down <chris@chrisdown.name>2018-12-03 16:40:31 +0100
commitc72703e26d21cb4994f21ae50c4e18675b02ded3 (patch)
treec2f6cf0b7772548594323b2c98aa6bea387b303e /man/systemd.resource-control.xml
parentcgroup: Traverse leaves to realised cgroup to release controllers (diff)
downloadsystemd-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.xml21
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>