There are only 3 CPU scaling governors on AMD Ryzen with acpi-cpufreq driver

English Hardware
1

I’m currently running Tumbleweed with kernel 6.3.2-1-default, on a Thinkpad T14 with AMD Ryzen 7 4750U. With turbo boost on, it usually runs very hot, constantly fluctuating between 65 to 80 Celcius.

I want to switch to conservative or powersave CPU scaling governor to lower temperature. However, I can only find 3 available governors: ondemand, schedutil & performances. As far as I know, the acpi-cpufreq scaling driver should have other governors such as powersave, conservative or userspace. These governors also existed in my previous Debian installation.

Does anyone know the reason for this lack of CPU scaling governors?

2

Show the output from following commands:

ls /usr/lib/modules/$(uname -r)/kernel/drivers/cpufreq/

cpupower frequency-info
3

Thank you for replying. Here are the outputs of the 2 commands:

ls /usr/lib/modules/$(uname -r)/kernel/drivers/cpufreq/

acpi-cpufreq.ko.zst
amd_freq_sensitivity.ko.zst
cpufreq_conservative.ko.zst
cpufreq_powersave.ko.zst
cpufreq_userspace.ko.zst
pcc-cpufreq.ko.zst
powernow-k8.ko.zst

cpupower frequency-info

analyzing CPU 7:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 7
  CPUs which need to have their frequency coordinated by software: 7
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 1.40 GHz - 1.70 GHz
  available frequency steps:  1.70 GHz, 1.60 GHz, 1.40 GHz
  available cpufreq governors: ondemand performance schedutil
  current policy: frequency should be within 1.40 GHz and 1.70 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.40 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: no
4

Your system is still using acpi-cpufreq instead of amd-pstate.

You can try to add following to the kernel command line (press “e” in grub menu):

initcall_blacklist=acpi_cpufreq_init amd_pstate.shared_mem=1

Boot with these parameters and execute following command again to check if it had any impact:

cpupower frequency-info

As these commands are not permanent now, nothing will get damaged if it doesn’t work. A second reboot will return to the old settings…

1 Like
5

Thank you. I will try that.
Howerver, I still wonder: isn’t acpi-cpufreq also supposed to have other governors like powersave or conservative? Does Tumbleweed implement a different version of acpi-cpufreq from other distros?

6

No. But newer AMD CPUs need other drivers as Intel CPUs or older pre Zen AMD CPUs.
https://docs.kernel.org/admin-guide/pm/amd-pstate.html

It is also possible that your BIOS settings are wrong or you have borked firmware. But i would start with testing amd-pstate drivers as mentioned.

7

According to this output, turbo boost is disabled. You still experience high temperatures?

On my intel system I went a different path while troubleshooting freezes:

$ systemctl cat cpupower.service
# /etc/systemd/system/cpupower.service
[Unit]
Description=Sets maximum CPU frequency

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set -u 3.6GHz

[Install]
WantedBy=multi-user.target

3.6GHz is the CPU base frequency, but I could set to even lower values. Capping frequency at base frequency decreased temperatures. Switching governors/bias didn’t.

8

I don’t understand why the output showed that boost is inactive, but the frequency stats evidently shows that the machine is on turbo boost.
I’ll keep your solution in mind, but capping the cpu doesn’t feel right to me. Thank you for your inputs.

9

Your output shows that your CPU can not even reach Turbo frequency 4,1 GHz as all cores are capped at base frequency of 1,7 GHz.

10

I think that output is incorrect, because when I watched CPU frequency live (with the command watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq), it showed that my frequency was way above 1,7GHz. I benchmarked the cpu with 7z b too, and the result is definitely not something this machine can achieve with boost off (Avr 34783).

Btw, I tried your solution (I added initcall_blacklist=acpi_cpufreq_init amd_pstate.shared_mem=1 to the Kernel Paramerters in Yast), and here is the result of cpu frequency info:

cpupower frequency-info

analyzing CPU 14:
  no or unknown cpufreq driver is active on this CPU
  CPUs which run at the same hardware frequency: Not Available
  CPUs which need to have their frequency coordinated by software: Not Available
  maximum transition latency:  Cannot determine or is not supported.
Not Available
  available cpufreq governors: Not Available
  Unable to determine current policy
  current CPU frequency: Unable to call hardware
  current CPU frequency:  Unable to call to kernel
  boost state support:
    Supported: yes
    Active: no

I guess I’ll have to install amd-pstate then?

11

Update: it seems like my current BIOS version does not support CPPC yet:

$ dmesg|grep -i pstate
[    0.505359] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled

All Thinkpad T14 up to Gen 3 with AMD CPU seem to share this problem, event with the latest BIOS version (1.43): English Community-Lenovo Community
The last page (8th) of the above link said that “with kernel 6.3, the amd_pstate drivers is now joined by the amd_pstate_epp driver”. As my current kernel is 6.3.1, I’ll try that and report back soon.

12

In the end, I think enabling the CPPC is required to use amd_pstate. However, that feature is still locked as of BIOS version 1.43 on my Thinkpad T14.
If anyone still wants to use amd_pstate, they’ll need enable CPPC in the BIOS: Advanced > AMD CBS > NBIOS Common Options > SMU Common Options > CPPC > CPPC CTRL.
If that option is not available, flashing the BIOS to bypass the lock is required, using Smokeless_UMAF: GitHub - DavidS95/Smokeless_UMAF.
Then:

For me, I guess I’ll stick with acpi_cpugreq for now

13

Yeah, preventing use of all resources is unoptimal, but in fairness that’s what the cpufreq’s governors powersave/userspace do.

Anyway, temperatures you reported are reasonable. Some governors will reach higher frequencies when there’s demand, and consequently CPU runs hotter. With higher temperatures running beyond base frequency then active cooling should kick in (fans).

To confirm, can you post the output of running sensors?

Also you could switch to the schedutil acpi_cpufreq governor instead. Governor ondemand will dial up to max frequency when needed.

14

Thank you for your replies.
I have tried both the ondemand and schedutil governors, but both yield the same result. Here is the temperature graph from psensor (a GUI for lm-sensor) from Wednesday, with schedutil governor (The orange line is the temperature, and the dark red line is CPU usage):

schedutil_2023-05-17_15-54-06
schedutil_2023-05-17_15-54-061924×1056 385 KB

As you can see, the temperature fluctuated between 50 to 65, and occasionally jumped to over 70 underload.

And here is the graph for ondemand governor, with the same workload:

ondemand_2023-05-17_15-04-35
ondemand_2023-05-17_15-04-351916×1053 367 KB

In my previous Debian installation with kernel 5.10, I used conservative governor, which is similar to ondemand, but with more gradual approach. However, that option does not show up in this Tumbleweed installation with kernel 6.3.2.
I think I’ll just stick with the current configs, and maybe repaste the machine to lower the temperature. Switching to amd_pstate as @hui’s suggestion sounds positive, but that requires a BIOS flashing, which I can’t risk attempting right now (but will try in the future).
I very much appreciate you guys’ inputs!

15

Honestly, the temperatures itself are not that high and also not dangerous for your hardware/CPU. The problem are these tiny, flat 14" laptops with no proper space for natural cooling. So the most time the fans have to run at max speed and then the laptop sounds like a starting jetfighter.
I also have one of these noise-boxes in my collection of hardware…

1 Like
16

The charts don’t show the high/crit thresholds that are available in sensors output.

According to kernel docs:

CPUFreq provides generic scaling governors that can be used with all scaling drivers. As stated before, each of them implements a single, possibly parametrized, performance scaling algorithm.

Did you tried setting conservative as scaling governor? In case you did and it didn’t work, would it possible a different scaling driver was in use in Debian?

17

Here is my current sensors output, in case it help

iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:        +50.0°C  

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +62.9°C  

amdgpu-pci-0700
Adapter: PCI adapter
vddgfx:      731.00 mV 
vddnb:       749.00 mV 
edge:         +45.0°C  
PPT:           4.00 W  

BAT0-acpi-0
Adapter: ACPI interface
in0:          12.48 V  

thinkpad-isa-0000
Adapter: ISA adapter
fan1:           0 RPM
fan2:           0 RPM
CPU:          +63.0°C  
GPU:           +0.0°C  
temp3:         +0.0°C  
temp4:         +0.0°C  
temp5:         +0.0°C  
temp6:         +0.0°C  
temp7:         +0.0°C  
temp8:            N/A  

nvme-pci-0100
Adapter: PCI adapter
Composite:    +46.9°C  (low  = -273.1°C, high = +83.8°C)
                       (crit = +84.8°C)
Sensor 1:     +46.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2:     +44.9°C  (low  = -273.1°C, high = +65261.8°C)

I did try to set conservative as governor (via TLP), but it said that the governor is not available.
I don’t remember which driver I used on Debian, but it likely to be acpi_cpufreq. can’t be amd_psate, because CPPC is not supported by my BIOS.

18

Thats not even necessary as the max allowed temp for a ryzen 7 pro 4750u is
378.15 K (105 °C, 221 °F, 680.67 °R)

So the TOs reached max temp of 84°C is far away from any treshold to worry about…
The noise of the fans is the problem.

The difference of the available governors are the kernel versions. As the kernel 6.x series tries to implement the new AMD drivers for the Zen2/Zen3/Zen… CPU series, it has other governors available as the old 5.10 kernel from Debian.

19

Hi,
This is my output of cpupower.

cpupower frequency-info
analyzing CPU 0:
  driver: intel_cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 20.0 us
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: ondemand performance schedutil
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.90 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    25500 MHz max turbo 4 active cores
    25500 MHz max turbo 3 active cores
    25500 MHz max turbo 2 active cores
    25500 MHz max turbo 1 active cores

If you noticed, I also have three available choices, they are “ondemand performance schedutil”
Here is the output of the command

cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor
schedutil
schedutil
schedutil
schedutil
schedutil
schedutil
schedutil

I tried to changed it to powersave even though it is a missing option base from the first code I pasted. Like so.

echo powersave | sudo tee /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor

And it resulted to this:

cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave

My question is, is this ligitimate? or forcing it this way will work?

1 Like
20

On theory, the powersave governor should put your CPU at minimal frequency (which is 1.60GHz). You can test whether this is true by checking your CPU frequency.
Could you show the output of this command?
watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq