Bugzilla – Bug 1074067
Linux does not obey nice level of process running under systemd
Last modified: 2018-08-01 13:20:31 UTC
Process niceness is obeyed when run from a terminal, but not when running as a systemd service. I would not be surprised if there was some cgroup trickery option I could/should have used (that's above me), but I'm flabbergasted that simple process niceness doesn't work by default, and that what you get instead (probably because of cgroups) is effectively a bit opposite. This systemd service does not do what its description says, and I'm unable to fix it: ---8<--- [Unit] Description=Dummy CPU load for 4 threads, as non-intrusive as possible [Service] User=boinc Nice=19 ExecStart=/bin/sh -c 'n="$(python3 -c "print((1<<(1<<9)) + 1)")"; factor "$n" | factor "$n" | factor "$n" | factor "$n"' # Doesn't help either #CPUSchedulingPolicy=idle #CPUWeight=1 #ControlGroup=cpu:/background --->8--- Based on https://anonscm.debian.org/cgit/pkg-boinc/boinc.git/tree/debian/boinc-client.service?id=399eee2dbfd6c2f94fcb391ac430eaf6d2a37e9f Reproduction steps: 1. Adjust the above systemd service for the number of CPU threads and run it. 2. Watch htop: Blue CPU load is "nice"; green is normal. 3. See if niceness is obeyed: Run the same command (as the value of ExecStart=) in another terminal. Expected behavior: Niceness is obeyed: Practically no blue CPU load in htop whenever there are enough more important tasks to run. Actual behavior: Half of my 4 CPU cores seem devoted to the "nice" CPU load, regardless of the amount of more important tasks. Version info: systemd 234-9.1 linux 4.14.2-1-default
I see there is now a "boinc-client" openSuSE package (progress!), and its systemd file contains these paramaters as well: CPUSchedulingPolicy=batch Slice=background.slice But same problem :-(
Is there supposed to be anything about the "background.slice" cgroup that makes it suitable for backgroud processes? Cpu shares is at 1024 (default value), but that's fixable echo 1 | sudo tee /sys/fs/cgroup/cpu/background.slice/cpu.shares … and that solves my problem!
Sorry for the delay... I just gave it a test and it behaves as expected. I reused the service you provided (except that User= was changed to my uid). In parallel I started 4 "factor" processes as root with default prio. The number of CPUs in my case was 4. htop showed: > PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command > 2306 root 20 0 8648 920 848 R 100. 0.1 2:21.85 factor 222222222222222222222222222222222222 > 2305 root 20 0 8648 816 740 R 100. 0.1 2:21.71 factor 222222222222222222222222222222222222 > 2308 root 20 0 8648 888 812 R 100. 0.1 2:20.31 factor 222222222222222222222222222222222222 > 2307 root 20 0 8648 884 808 R 94.2 0.1 2:14.69 factor 222222222222222222222222222222222222 > 2302 fbui 39 19 7392 904 832 R 1.3 0.1 0:07.25 factor 134078079299425970995740249982058461 > 2301 fbui 39 19 7392 900 828 R 1.3 0.1 0:07.33 factor 134078079299425970995740249982058461 > 2304 fbui 39 19 7392 900 824 R 1.3 0.1 0:07.38 factor 134078079299425970995740249982058461 > 2303 fbui 39 19 7392 832 760 R 1.3 0.1 0:07.18 factor 134078079299425970995740249982058461 > 2067 root 20 0 22456 4032 3020 R 0.7 0.4 0:02.84 htop As you can see the service's processes are run with a lower priority than the ones spawned by root (which had the default prio) and they get most of the CPUs. So I'm closing this bug as it seems to be working. If you're still facing this issue with *latest* TW, feel free to re-open.