Bug 1074067 - Linux does not obey nice level of process running under systemd
Linux does not obey nice level of process running under systemd
Status: RESOLVED WORKSFORME
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
x86-64 SUSE Other
: P5 - None : Normal (vote)
: ---
Assigned To: systemd maintainers
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-12-25 13:44 UTC by Andreas Nordal
Modified: 2018-08-01 13:20 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Nordal 2017-12-25 13:44:21 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
Comment 1 Andreas Nordal 2017-12-25 15:20:15 UTC
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 :-(
Comment 2 Andreas Nordal 2017-12-27 08:52:00 UTC
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!
Comment 5 Franck Bui 2018-08-01 13:20:31 UTC
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.