CPU scaling governor issues

Ask Fedora
1

Hello, while fiddling with my two currently acitve rigs (see below) I’ve observed some strange behaviour:

  • On 1 the CPU scaling driver has been set to intel_pstate in passive mode which is to be expected as of Linux 5.8 from Sandy Bridge to Broadwell. The scaling governor is now set to ondemand by default which for some reasons is not Intel’s preferred option but schedutil.
  • On 2 the scaling governor is set to conservative by default which isn’t optimal either but maybe okayish for most use cases.
  • Setting the scaling governor on 2 to schedutil works most of the time but not when doing this with a oneshot systemd unit on boot. It’s switched back to conservative immediately which is not optimal behaviour.
  • Starting the cpupower.service (to set the scaling governor permanently) leads to both 1 and 2 immediately reaching their highest available clock speeds (within their power budget, with 1 boosting and 2 not boosting) and keeping them all the way up. This should not be normal behaviour (I hope).

Are these issues reproducible or has anyone experienced similar behaviour?

1: Core i5 4570S [Intel Haswell]
2: Ryzen 5 3500X [AMD Zen2]

2

Hi @eriba1adad , welcome to the community! Please take a minute to go through the introductory post in the #start-here category if you’ve not had a chance to do so yet. It includes information on how to use the forum effectively.

What commands do you use to change the settings you mention?

3

Hello @rele, thanks for the welcome.

To change the scaling governor I used

sudo cpupower frequency-set -g schedutil

The systemd oneshot unit looks like this:

[Unit]
Description=Set CPU scaling governor to "schedutil"

[Service]
Type=oneshot
ExecStart=/bin/sh -c "cpupower frequency-set -g schedutil"

[Install]
WantedBy=multi-user.target
4

I tried a machine with AMD Ryzen 3 2200G and has ondemand as default scaling governor. Changed it to schedutil and started cpupower.service:

grep MH /proc/cpuinfo
cpu MHz : 2847.189
cpu MHz : 2851.620
cpu MHz : 2852.135
cpu MHz : 2856.469

lscpu |grep MH
CPU MHz: 2844.986
CPU max MHz: 3500.0000
CPU min MHz: 1600.0000

So this AMD is not maxing out.

Another machine with Intel Core i5-8400 has powersave as default scaling governor.

$ cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 800 MHz - 4.00 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 4.00 GHz.
The governor “powersave” may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 800 MHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes

And schedutil does not seem available here.
Both are running Fedora 32.

5

Your AMD machine doesn’t seem to reach its lowest state either, does it? Differences (according to spec):

CPU   MIN  BASE BOOST
2200G 1600 3500 3700
3500X 2200 3600 4100
4570S  800 2900 3600

Yours is clocking somewhere between minimum and base clock, my AMD at base clock and my Intel at boost clock. None of this is optimal.

Regarding your Intel machine its behaviour is as expected: intel_pstate driver in active mode only supports powersave and performance governors which is perfectly fine. Could you please test its behaviour when starting cpupower.service?

6

Before starting cpupower.service on the AMD it looked like

grep MH /proc/cpuinfo
cpu MHz : 1591.574
cpu MHz : 1593.378
cpu MHz : 1585.207
cpu MHz : 1634.488

so there was a change.

On the intel:

$ systemctl status cpupower.service
● cpupower.service - Configure CPU power related settings
Loaded: loaded (/usr/lib/systemd/system/cpupower.service; disabled; vendor preset: disabled)
Active: active (exited) since Sun 2020-10-04 12:20:38 CEST; 21s ago
Process: 105445 ExecStart=/usr/bin/cpupower $CPUPOWER_START_OPTS (code=exited, status=0/SUCCESS)
Main PID: 105445 (code=exited, status=0/SUCCESS)
CPU: 2ms

Oct 04 12:20:38 six systemd[1]: Starting Configure CPU power related settings…
Oct 04 12:20:38 six cpupower[105445]: Setting cpu: 0
Oct 04 12:20:38 six cpupower[105445]: Setting cpu: 1
Oct 04 12:20:38 six cpupower[105445]: Setting cpu: 2
Oct 04 12:20:38 six cpupower[105445]: Setting cpu: 3
Oct 04 12:20:38 six cpupower[105445]: Setting cpu: 4
Oct 04 12:20:38 six cpupower[105445]: Setting cpu: 5
Oct 04 12:20:38 six systemd[1]: Finished Configure CPU power related settings.

$ cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 800 MHz - 4.00 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 4.00 GHz.
The governor “performance” may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 3.90 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes

$ grep MH /proc/cpuinfo
cpu MHz : 3916.891
cpu MHz : 3928.855
cpu MHz : 3926.277
cpu MHz : 3844.885
cpu MHz : 3952.048
cpu MHz : 3896.726

$ lscpu |grep MH
CPU MHz: 3885.143
CPU max MHz: 4000.0000
CPU min MHz: 800.0000

So the intel is almost maxing out.

1 Like
7

Okay, the solution is too obvious. :roll_eyes: The cpupower.service reads a file /etc/sysconfig/cpupower which by default holds following options:

CPUPOWER_START_OPTS="frequency-set -g performance"
CPUPOWER_STOP_OPTS="frequency-set -g ondemand"

Setting the performance governor to performance instantly ramps up the CPU clock. Therefore this config file has to be edited for desired behaviour.

Thanks for your support anyway!

1 Like