PVE 9.0 CPU Scaling Governor not working anymore

[Philebos]

Hello,

since upgrading to PVE 9.0 the CPU Scaling Governor doesn't seem to work anymore. The cpu-frequency stays the same no matter the chosen power profile (e.g., powersave vs. performance).

In PVE 8 it worked very well with a significant reduction in power-usage with “powersave”.

I did some experiments with different hardware and it's always the same: In PVE 8 and it works, PVE 9 and it doesn't.

Am I missing something

The commands I use:

changing the profile:

echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

verifying the active profile:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

 

[leesteken]

Please ask the creators/maintainers of the script to fix their script. Those scripts are not provided nor supported by Proxmox and have their own place for issues and discussions: https://github.com/community-scripts/ProxmoxVE

WARNING: The post by ShaunRutherford below quoted my message but added their own spam link to it. Please ignore and/or report it.

 

[keeka]

@Philebos I'm not familiar with the script you mention or what it's function is. I am currently setting governor by just passing kernel boot parm `cpufreq.default_governor=ondemand`.
Are you saying (having confirmed the governor has been set successfully) that for a given governor, you see different frequency scaling behaviour under PVE9 cvompared to PVE8?
I've yet uo upgrade so haven't tested this myself.

 

[Philebos]

The problem isn't with the script because it doesn't work with the terminal commands either.

Today I reverted to PVE 8.0 on my production machine. I guess I upgraded too early...

 

[Monstrous1704]

Downstream issue, all my VM's are now missing the cpu frequency details so alot of pass through virtualization is completely broken:

open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)

Seems related to Proxmox / Qemu / Kernal update, was fine before PVE 9

 

[uzumo]

I don't think lowering the CPU frequency will save much power.
If you lower it, the virtual machines won't run.
I think it would be a waste of time.

If you don't know how to undo it, don't do it.

udevadm info --attribute-walk --path=/devices/system/cpu/cpu0 | grep 'scaling_min_freq'
touch /etc/udev/rules.d/99-cpufreq-scaling-min-freq.rules
nano /etc/udev/rules.d/99-cpufreq-scaling-min-freq.rules
SUBSYSTEM=="cpu", KERNEL=="cpu[0-9]|cpu[0-9][0-9]", ACTION=="add|change", RUN="/usr/bin/bash -c 'echo 550000 > /sys/devices/system/cpu/%k/cpufreq/scaling_min_freq'"
udevadm control --reload
udevadm trigger

 

[hastmu]

Hi everybody,
independent from any script, i share the following observation from myside:

root@pve03-ryzen:/lib/modules# ls -la */kernel/drivers/cpufreq/*
-rw-r--r-- 1 root root 12020 27. Aug 10:10 6.12.43+deb13-amd64/kernel/drivers/cpufreq/acpi-cpufreq.ko.xz
-rw-r--r-- 1 root root  2972 27. Aug 10:10 6.12.43+deb13-amd64/kernel/drivers/cpufreq/amd_freq_sensitivity.ko.xz
-rw-r--r-- 1 root root  4232 27. Aug 10:10 6.12.43+deb13-amd64/kernel/drivers/cpufreq/cpufreq_conservative.ko.xz
-rw-r--r-- 1 root root  6864 27. Aug 10:10 6.12.43+deb13-amd64/kernel/drivers/cpufreq/cpufreq_ondemand.ko.xz
-rw-r--r-- 1 root root  2020 27. Aug 10:10 6.12.43+deb13-amd64/kernel/drivers/cpufreq/cpufreq_powersave.ko.xz
-rw-r--r-- 1 root root  3440 27. Aug 10:10 6.12.43+deb13-amd64/kernel/drivers/cpufreq/cpufreq_userspace.ko.xz
-rw-r--r-- 1 root root  4724 27. Aug 10:10 6.12.43+deb13-amd64/kernel/drivers/cpufreq/p4-clockmod.ko.xz
-rw-r--r-- 1 root root  7380 27. Aug 10:10 6.12.43+deb13-amd64/kernel/drivers/cpufreq/pcc-cpufreq.ko.xz
-rw-r--r-- 1 root root 13144 27. Aug 10:10 6.12.43+deb13-amd64/kernel/drivers/cpufreq/powernow-k8.ko.xz
-rw-r--r-- 1 root root  4180 27. Aug 10:10 6.12.43+deb13-amd64/kernel/drivers/cpufreq/speedstep-centrino.ko.xz
-rw-r--r-- 1 root root  5756 27. Aug 10:10 6.12.43+deb13-amd64/kernel/drivers/cpufreq/speedstep-lib.ko.xz
-rw-r--r-- 1 root root 11473 12. Sep 11:46 6.14.11-2-pve/kernel/drivers/cpufreq/amd_freq_sensitivity.ko
-rw-r--r-- 1 root root 20977 12. Sep 11:46 6.14.11-2-pve/kernel/drivers/cpufreq/p4-clockmod.ko
-rw-r--r-- 1 root root 28009 12. Sep 11:46 6.14.11-2-pve/kernel/drivers/cpufreq/speedstep-lib.ko
-rw-r--r-- 1 root root 11473 10. Okt 10:04 6.14.11-4-pve/kernel/drivers/cpufreq/amd_freq_sensitivity.ko
-rw-r--r-- 1 root root 20977 10. Okt 10:04 6.14.11-4-pve/kernel/drivers/cpufreq/p4-clockmod.ko
-rw-r--r-- 1 root root 28009 10. Okt 10:04 6.14.11-4-pve/kernel/drivers/cpufreq/speedstep-lib.ko
-rw-r--r-- 1 root root 46473 21. Okt 13:55 6.17.2-1-pve/kernel/drivers/cpufreq/amd_freq_sensitivity.ko
-rw-r--r-- 1 root root 44833 21. Okt 13:55 6.17.2-1-pve/kernel/drivers/cpufreq/p4-clockmod.ko
-rw-r--r-- 1 root root 52065 21. Okt 13:55 6.17.2-1-pve/kernel/drivers/cpufreq/speedstep-lib.ko
-rw-r--r-- 1 root root 10209 12. Sep 13:02 6.8.12-15-pve/kernel/drivers/cpufreq/amd_freq_sensitivity.ko
-rw-r--r-- 1 root root 17993 12. Sep 13:02 6.8.12-15-pve/kernel/drivers/cpufreq/p4-clockmod.ko
-rw-r--r-- 1 root root 25761 12. Sep 13:02 6.8.12-15-pve/kernel/drivers/cpufreq/speedstep-lib.ko

it looks like that 6.14 and 6.17 branches of the kernel do no longer ship cpufreq_govenors as 6.12.

But it pointed out that this is just an old skool understand from my side, actually:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
amd-pstate-epp

Revealed that my ryzen cpu is handled by a "new" module, therefore that also works different.
Which i have to figure out - keep you posted.

 

[hastmu]

as expected this is handled differently now:

amd_pstate = active provides:
performance and powersave govneors

amd_pstate = passive provides
conservative ondemand userspace powersave performance schedutil

amd_pstate = guided provides
governors: conservative ondemand userspace powersave performance schedutil

this provides the current status - cpupower frequency-info the insight on govnors available
cat /sys/devices/system/cpu/amd_pstate/status

full details under: https://docs.kernel.org/admin-guide/pm/amd-pstate.html