Setting CPU frequencies with cpupower has no effect

Question

I tried it on desktop Ubuntu 22.04.3, 23.10, regular and lowlatency versions. I have to increase the minimum frequency of a core, which runs an image capture process requiring high CPU clock. Here is an example:

paul@box4x4:~$ sudo cpupower -c 5 frequency-set -d 3000MHz
Setting cpu: 5

which sets the minimum frequency for core #5, but the actual frequency doesn't change:

paul@box4x4:~/profiler$ cpupower -c 5 frequency-info
analyzing CPU 5:
  driver: amd-pstate-epp
  CPUs which run at the same hardware frequency: 5
  CPUs which need to have their frequency coordinated by software: 5
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 5.58 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 3.00 GHz and 5.58 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 400 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: no

and stays and glacial 400MHz. Am I doing it wrong? Is there another, hopefully not too cumbersome, way and tool to accomplish it?

One red flag with I see here is a bogus maximum frequency of 5.58GHz. It is not possible. 4.9GHz is the maximum turbo frequency for AMD Ryzen 5 7640U CPU I'm using.

---

I did a sanity test on Intel N100 PC and it seems to work there:

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

Core #3 frequency reaches requested 3.4GHz, but sometimes reading lower when monitored with watch grep \"cpu MHz\" /proc/cpuinfo. Still, vastly better than the results on AMD CPU.

Answer 1

The problem here is the driver: amd-pstate-epp. It is trying to be too smart, so let's disable it:

1. sudo vim /etc/default/grub
2. Find the line with GRUB_CMDLINE_LINUX_DEFAULT=
3. Add amd_pstate=disable inside the double quotes. If there are other items, add this to the end, and separate it from the previous items with a space.
4. Save and exit
5. Run sudo update-grub
6. reboot
7. Retry your original sudo cpupower -c 5 frequency-set -d 3000MHz

The EPP in amd-pstate-epp stands for energy_performance_preference. It might also have some kind of interaction with the "CPUs which run at the same hardware frequency [...and...] need to have their frequency coordinated by software". According to the docs, the

amd_pstate_epp driver provides a hint to the hardware if software wants to bias toward performance (0x0) or energy efficiency (0xff) to the CPPC firmware. then CPPC power algorithm will calculate the runtime workload and adjust the realtime cores frequency according to the power supply and thermal, core voltage and some other hardware conditions.

and the other modes are similar. The amd-pstate attribute controls which strategy it will use, if at all.

The acpi-cpufreq driver is the old one. It usually just does what you tell it to do. In this case, you do indeed want to "increase the minimum frequency of a core," based on your specialized knowledge that it is going to be used for "an image capture process," so you need this driver.

Answer 2

In my case switching to acpi-cpufreq did not help (Debian 13 Trixie RC1, kernel 6.12.27).

Solved by building and installing fresh 6.14.9 kernel from the sources, in this case frequency is controlled even using the default amd-pstate-epp driver. It also works out of the box in Arch.