mirror of
https://github.com/systemd/systemd-stable.git
synced 2025-01-24 02:03:54 +03:00
c72703e26d
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.
The extended testsuite only works with UID=0. It contains of several subdirectories named "test/TEST-??-*", which are run one by one. To run the extended testsuite do the following: $ ninja -C build # Avoid building anything as root later $ sudo test/run-integration-tests.sh ninja: Entering directory `/home/zbyszek/src/systemd/build' ninja: no work to do. --x-- Running TEST-01-BASIC --x-- + make -C TEST-01-BASIC BUILD_DIR=/home/zbyszek/src/systemd/build clean setup run make: Entering directory '/home/zbyszek/src/systemd/test/TEST-01-BASIC' TEST CLEANUP: Basic systemd setup TEST SETUP: Basic systemd setup ... TEST RUN: Basic systemd setup [OK] make: Leaving directory '/home/zbyszek/src/systemd/test/TEST-01-BASIC' --x-- Result of TEST-01-BASIC: 0 --x-- --x-- Running TEST-02-CRYPTSETUP --x-- + make -C TEST-02-CRYPTSETUP BUILD_DIR=/home/zbyszek/src/systemd/build clean setup run If one of the tests fails, then $subdir/test.log contains the log file of the test. To run just one of the cases: $ sudo make -C test/TEST-01-BASIC clean setup run Specifying the build directory ============================== If the build directory is not detected automatically, it can be specified with BUILD_DIR=: $ sudo BUILD_DIR=some-other-build/ test/run-integration-tests or $ sudo make -C test/TEST-01-BASIC BUILD_DIR=../../some-other-build/ ... Note that in the second case, the path is relative to the test case directory. An absolute path may also be used in both cases. Configuration variables ======================= TEST_NO_QEMU=1 can be used to disable qemu tests. TEST_NO_NSPAWN=1 can be used to disable nspawn tests. KERNEL_APPEND='...' can be used to add additional kernel parameters for the QEMU runs. The kernel and initramfs can be specified with $KERNEL_BIN and $INITRD. (Fedora's or Debian's default kernel path and initramfs are used by default) A script will try to find your QEMU binary. If you want to specify a different one with $QEMU_BIN. Debugging the qemu image ======================== If you want to log in the testsuite virtual machine, you can specify additional kernel command line parameter with $KERNEL_APPEND and then log in as root. $ sudo make -C test/TEST-01-BASIC KERNEL_APPEND="systemd.unit=multi-user.target" run Root password is empty.