[solved] cpupower unable to set performance governor at boot

[MorgothSauron]

Hello,
I'm trying to use sys-power/cpupower to change the CPU scaling governor from 'powersave' to 'performance' at boot, but I always end up with 'powersave'. At least this is my conclusion based on everything I verified.

I have cpupower 6.2.0 installed

Code: Select all

root@morgoth:~ # eix sys-power/cpupower
[I] sys-power/cpupower
     Available versions:  5.18(0/0) 6.2(0/0) {nls}
     Installed versions:  6.2(0/0)(06:36:24 PM 06/05/2024)(nls)
     Homepage:            https://www.kernel.org/
     Description:         Shows and sets processor power related values

root@morgoth:~ # cpupower --version
cpupower 6.2.0
Report errors and bugs to linux-pm@vger.kernel.org, please.
root@morgoth:~ # 

I changed the START_OPTS value in /etc/conf.d/cpupower to set governor to 'performance' instead of the default (ondemand). This is the only change I made to this file.

Code: Select all

root@morgoth:~ # grep START_OPTS /etc/conf.d/cpupower 
##START_OPTS="--governor ondemand"
START_OPTS="--governor performance"
root@morgoth:~ # 

Finally, I added the cpupower service to start at boot

Code: Select all

rc-update add cpupower default

I can see in /var/log/rc.log that the cpupower command is executed at boot with the option I set in the configuration:

Code: Select all

 * Running cpupower -c all frequency-set --governor performance ...
 [ ok ]

However, the governor is set to 'powersave':

Code: Select all

# cpupower frequency-info
analyzing CPU 7:
  driver: intel_pstate
  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: 800 MHz - 4.90 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 4.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 4.69 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

Running the command manually using the command from rc.log seems to work:

Code: Select all

root@morgoth:~ # cpupower -c all frequency-set --governor performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7
root@morgoth:~ # cpupower frequency-info
analyzing CPU 2:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 800 MHz - 4.90 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 4.90 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 4.79 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
root@morgoth:~ # 

The performance governor is normally the one set as the default in the kernel configuration:

Code: Select all

-*- CPU Frequency scaling
[*]   CPU frequency transition statistics
      Default CPUFreq governor (performance)  --->
-*-   'performance' governor
<M>   'powersave' governor
<*>   'userspace' governor for userspace frequency scaling
< >   'ondemand' cpufreq policy governor
< >   'conservative' cpufreq governor

root@morgoth:~ # zcat /proc/config.gz | grep CPU_FREQ_GOV_PERFORMANCE
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
root@morgoth:~ # 

I could not find anything else that could explain this behavior

Any idea why 'powersave' seems to be the "active" governor at boot although the cpupower service is executed with the right parameter to set it to 'performance' ?

Am I missing something important here ?

Thanks

[Pearlseattle]

That's weird!
(but I never used "cpupower" so I don't know anything specific about it)

Extreme wild guess:
maybe it happens because you compile "powersave" as module but "performance" as embedded in the kernel?
Therefore maaaybe "performance" is set right when the kernel is loaded, but then when your modules-directory is mounted the kernel sees a compatible governor that is available ("powersave") and therefore loads it? And/or then maybe there is a race condition with the start of "cpupower" vs. load of available modules and what I wrote in my previous sentence happens after "cpupower" is started?

Therefore, here is my proposal #1:
compile "powersave" as well embedded (not as a module) and see if that changes anything?


Otherwise, just to be 200% sure: whenever you check then check all vCPUs, just to be sure that they're all the same:
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Maybe you could try to write your own (as "root") "/etc/init.d/mycustom-cpu_governor" like for example...

Code: Select all

#!/sbin/openrc-run

start() {
        echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null
        }
stop() {
        echo nothing2do
        }

...then "chmod 700 /etc/init.d/mycustom-cpu_governor", then test it with "/etc/init.d/mycustom-cpu_governor start" and if that works then add it to the boot sequence with "rc-update add mycustom-cpu_governor default" and then reboot and then finally check the result with "cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor"?
If this would not work (you would still see "powersave" being used, but when executing "/etc/init.d/mycustom-cpu_governor start" then it works, then I'd guess that you most probably have "something else" that is executed later in the boot sequence that makes you use "powersave"...?


Cheers

[pietinger]

The performance governor is normally the one set as the default in the kernel configuration:

Code: Select all

-*- CPU Frequency scaling
[*]   CPU frequency transition statistics
      Default CPUFreq governor (performance)  --->
-*-   'performance' governor
<M>   'powersave' governor
<*>   'userspace' governor for userspace frequency scaling
< >   'ondemand' cpufreq policy governor
< >   'conservative' cpufreq governor

root@morgoth:~ # zcat /proc/config.gz | grep CPU_FREQ_GOV_PERFORMANCE
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
root@morgoth:~ # 

This means you are configuring your kernel yourself - this is an advantage. NOW ...

... usually you dont need cpupower at all, because the DEFAULT kernel setting decides which governor is used - this one:

Code: Select all

...
      Default CPUFreq governor (performance)  --->
...

and this will not be changed ... IF ... if there is no rc-script which is doing this ... so, I suggest to remove cpupower completely from your runlevel AND then check if the governor is changed after a fresh reboot. IF YES, THEN some other rc-script OR some application in your DE or WM is doing it !

I configure my kernel also myself and have set the default to "schedutil" - "performance" is enabled automatially because of "Selected by [y]: - X86_INTEL_PSTATE [=y] && CPU_FREQ [=y] && X86 [=y]" - all others are disabled.

Code: Select all

      Default CPUFreq governor (schedutil)  --->
-*-   'performance' governor
-*-   'schedutil' cpufreq policy governor

[Goverp]

I probably missed it above, but I don't see what sort of PC you have. So, making a wild guess, it's a laptop or equivalent (otherwise you might not be too concerned about power managers). In which case there might be some packages such as laptop-mode-tools that will play with cpu power settings. I think if you install KDE powerdevil, that too will alter settings without telling you. Such packages do this as a matter of course, as it's their primary function.

[pietinger]

The whole thing gave me no peace and I tested it myself today (as I don't normally use the rc-script "cpupower"). Result: The rc-script is not able to change the governor (*) and is therefore faulty for me. Manually I can change from "powersave" to "performance" (and back) with "cpupower" (Intel's P-State only recognizes this two).

*) I didnt changed the file /etc/conf.d/cpupower (default is there: START_OPTS="--governor powersave") and started my machine with my default from kernel "performance" ... It was still performance after starting this rc-script.

I then also looked at how the power preference changes:

Code: Select all

 /sys/devices/system/cpu/cpu0/cpufreq # cpupower -c all frequency-set --governor powersave
CPU einstellen: 0
...
CPU einstellen: 31
 /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_governor 
powersave
 /sys/devices/system/cpu/cpu0/cpufreq # cat energy_performance_preference 
balance_performance
 /sys/devices/system/cpu/cpu0/cpufreq # cpupower -c all frequency-set --governor performance
...
 /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_governor 
performance
 /sys/devices/system/cpu/cpu0/cpufreq # cat energy_performance_preference 
performance

I have also checked with which setting P-State starts if you set "performance" as default in the kernel configuration: Yes, it is/was "performance".

[MorgothSauron]

I probably missed it above, but I don't see what sort of PC you have. So, making a wild guess, it's a laptop or equivalent (otherwise you might not be too concerned about power managers). In which case there might be some packages such as laptop-mode-tools that will play with cpu power settings. I think if you install KDE powerdevil, that too will alter settings without telling you. Such packages do this as a matter of course, as it's their primary function.

I have a desktop computer with an i7-9700k CPU with a Gigabyte Z390 AORUS PRO motherboard.

I do have kde-plasma/powerdevil installed. The Power management profile option is not enabled, so there might be some default settings involved here. I will try to boot without logging in and check the governor value. It should confirm what is the value before opening a session. I will do this quick test and post back.

On a side note, I didn't have cpupower until few weeks ago. I had powersave before installing and enabling cpupower. I was looking for option to set to performance by default.

[MorgothSauron]

I'm not sure I understand what is really going on.

I booted and I didn't login in KDE (my only DE) and switched to a console instead (e.g. Ctrl+Alt+f5). The CPU scaling governor is still set to 'powersave'. I think it is safe to say that it is not related to something with KDE startup (e.g. powerdevil). cpupower service was still configured to start at boot.

In the same console I checked the value directly in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor to be sure. It is 'powersave'.

I removed cpupower from OpenRC startup (rc-update del cpupower default) and rebooted. Still the same.

I checked for all files under /etc. I could not find anything that would set the scaling governor to 'powersave'.

The local service is enabled, but I have nothing in /etc/local.d either.

But I decided to try to put my own script for the local service:

Code: Select all

root@morgoth:~ # cat /etc/local.d/cpufreq-scaling-governor-performance.start 
#
echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null 
#
root@morgoth:~ # 

I rebooted and this time cpupower frequency-info is showing 'performance'.

I have no clue why my script started by the 'local' service can do something that the 'cpupower' service doesn't seem to do. Also, I still don't understand that I end up with 'powersave' when 'performance' is set as the default in the kernel options. I must be missing something, but I don't know it yet.

I'll try to play around with this to see if I can really understand. For now the script started by the 'local' service will do the job.

[pietinger]

MorgothSauron,

IF you have "performance" as default in your kernel configured ... THEN ... check if you really boot the kernel you think you boot ->

Check with "dmesg | grep version" the version AND date of the kernel (it is the first line you will get). The date at the end is the date when this kernel was built (compiled). Usually you will install the kernel some seconds later into /boot ... NOW check also with "ls -l /boot" the timestamps of every kernel you have here ...

Maybe you use grub ? If yes ... the first kernel grub presents (and boots) is not always the last kernel you have compiled ...

[MorgothSauron]

pietinger,
Here are the details about the kernels on my system. It looks good to me.

/boot:

Code: Select all

root@morgoth:~ # date
Wed Jul  3 08:09:52 PM CEST 2024
root@morgoth:~ # ls -al /boot
total 109620
drwxr-xr-x 4 root root     4096 Jun 27 19:24 .
drwxr-xr-x 1 root root      134 Apr 27 12:49 ..
-rw-r--r-- 1 root root    77312 Jun 17 19:10 amd-uc.img
drwxr-xr-x 6 root root     4096 Jun 27 19:24 grub
-rw-r--r-- 1 root root  9054432 Jun 12 19:27 initramfs-6.9.4-gentoo-x86_64.img
-rw-r--r-- 1 root root  9059680 Jun 17 19:24 initramfs-6.9.5-gentoo-x86_64.img
-rw-r--r-- 1 root root  9057256 Jun 25 19:39 initramfs-6.9.6-gentoo-x86_64.img
-rw-r--r-- 1 root root  9060356 Jun 27 19:23 initramfs-6.9.7-gentoo-x86_64.img
-rw-r--r-- 1 root root   534528 Jun 27 18:06 intel-uc.img
-rw-r--r-- 1 root root        0 Nov 18  2020 .keep
drwx------ 2 root root    16384 Nov 21  2020 lost+found
-rw-r--r-- 1 root root  6732898 Jun 12 19:14 System.map-6.9.4-gentoo-x86_64
-rw-r--r-- 1 root root  6733110 Jun 17 19:15 System.map-6.9.5-gentoo-x86_64
-rw-r--r-- 1 root root  6733546 Jun 25 19:29 System.map-6.9.6-gentoo-x86_64
-rw-r--r-- 1 root root  6734861 Jun 27 19:14 System.map-6.9.7-gentoo-x86_64
-rw-r--r-- 1 root root 12100608 Jun 12 19:14 vmlinuz-6.9.4-gentoo-x86_64
-rw-r--r-- 1 root root 12100608 Jun 17 19:15 vmlinuz-6.9.5-gentoo-x86_64
-rw-r--r-- 1 root root 12108800 Jun 25 19:29 vmlinuz-6.9.6-gentoo-x86_64
-rw-r--r-- 1 root root 12108800 Jun 27 19:14 vmlinuz-6.9.7-gentoo-x86_64
root@morgoth:~ # 

I use initramfs because / is on a filesystem encrypted with LUKS. I use genkernel.

Running kernel is 6.9.7. The kernel file date match the build date.

Code: Select all

root@morgoth:/ # dmesg | grep "Linux version"
[    0.000000] Linux version 6.9.7-gentoo-x86_64 (root@morgoth) (x86_64-pc-linux-gnu-gcc (Gentoo 13.2.1_p20240210 p14) 13.2.1 20240210, GNU ld (Gentoo 2.42 p3) 2.42.0) #1 SMP PREEMPT_DYNAMIC Thu Jun 27 19:14:31 CEST 2024
root@morgoth:/ # 

root@morgoth:/ # uname -a
Linux morgoth 6.9.7-gentoo-x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jun 27 19:14:31 CEST 2024 x86_64 Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz GenuineIntel GNU/Linux
root@morgoth:/ # 

'perfomance' is set as the default in the running kernel configuration

Code: Select all

root@morgoth:~ # zcat /proc/config.gz | grep CPU_FREQ_DEFAULT_GOV_PERFORMANCE
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
root@morgoth:~ # 

I do use grub. I make sure to run grub-mkconfig -o /boot/grub/grub.cfg every time I make a change in /boot, like removing an old kernel.

The first menuentry in /boot/grub/grub.cfg is 6.9.7 as well.

Code: Select all

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-b7d7d156-3372-40ba-b71c-54542050af8b' {
        load_video
        if [ "x$grub_platform" = xefi ]; then
                set gfxpayload=keep
        fi
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root ac315056-593b-4566-94be-209a3f784d10
        echo    'Loading Linux 6.9.7-gentoo-x86_64 ...'
        linux   /vmlinuz-6.9.7-gentoo-x86_64 root=UUID=b7d7d156-3372-40ba-b71c-54542050af8b ro rootflags=subvol=@root init=/sbin/openrc-init keymap=us crypt_root=UUID=ec03044a-df21-4347-a166-49d65a17bf93 root=UUID=b7d7d156-3372-40ba-b71c-545420
50af8b rootflags=subvol=@root delayacct 
        echo    'Loading initial ramdisk ...'
        initrd  /intel-uc.img /amd-uc.img /initramfs-6.9.7-gentoo-x86_64.img
}

[pietinger]

MorgothSauron,

yes you are booting with a kernel which setting is "performance" as default ... I am sorry, I must give up ->

I have also a manually configured kernel (also 6.9.7 as you have; but NO initramfs) and had "performance" as default in my kernel configured (for testing) ... even with a KDE/Plasma system I had still "performce" after rebooting active ...

These are my rc-scripts:

Code: Select all

$ rc-update 
            alsasound | boot                                   
             apparmor | boot                                   
               binfmt | boot                                   
             bootmisc | boot                                   
              cgroups |                                 sysinit
              chronyd |      default                           
               cronie |      default                           
                devfs |                                 sysinit
      display-manager |      default                           
                dmesg |                                 sysinit
              elogind | boot                                   
                 fsck | boot                                   
             hostname | boot                                   
             iptables |      default                           
              keymaps | boot                                   
            killprocs |                        shutdown        
    kmod-static-nodes |                                 sysinit
                local |      default nonetwork                 
           localmount | boot                                   
             loopback | boot                                   
              modules | boot                                   
             mount-ro |                        shutdown        
                 mtab | boot                                   
           net.enp2s0 |      default                           
              osclock |      default                           
              privoxy |      default                           
               procfs | boot                                   
                 root | boot                                   
         save-keymaps | boot                                   
    save-termencoding | boot                                   
            savecache |                        shutdown        
              seedrng | boot                                   
                 swap | boot                                   
               sysctl | boot                                   
                sysfs |                                 sysinit
             sysklogd |      default                           
 systemd-tmpfiles-setup | boot                                   
 systemd-tmpfiles-setup-dev |                                 sysinit
         termencoding | boot                                   
                 udev |                                 sysinit
         udev-trigger |                                 sysinit
              unbound |      default

(maybe it helps to check if there is a suspicious script you use)

Maybe extract your initramfs and check what it does ?

( https://wiki.gentoo.org/wiki/Custom_Ini ... io_archive )

[MorgothSauron]

I checked the content of the initramfs and I couldn´t find anything related to CPU scaling.

I got the expected result using a script in /etc/local.d

Code: Select all

#

echo "$0"

# this works
# echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null 2>&1

# test if cpupower works in 'local' because the standalone 'cpupower' service doesn't seem to work
cpupower -c all frequency-set --governor performance

#

What is interesting is that both methods (echo and cpupower command) work. And the cpupower command is exactly the same as the cpupower service. This seems to indicate something related to service start order. I suspect it could be power-profiles-daemon, but I didn´t investigate this.

Code: Select all

root@morgoth:~ # rc-status                  
Runlevel: default
 sysklogd                                                                                                                                [  started  ]
 ntpd                                                                                                                                    [  started  ]
 cronie                                                                                                                                  [  started  ]
 libvirtd                                                                                                                                [  started  ]
 netmount                                                                                                                                [  started  ]
 display-manager                                                                                                                         [  started  ]
 freshclam                                                                                                                               [  started  ]
 clamd                                                                                                                                   [  started  ]
 pcscd                                                                                                                                   [  started  ]
 power-profiles-daemon                                                                                                                   [  started  ]
 sshd                                                                                                                                    [  started  ]
 local                                                                                                                                   [  started  ]
 agetty.tty6                                                                                                                 [  started 01:04:33 (0) ]
 agetty.tty5                                                                                                                 [  started 01:04:33 (0) ]
 agetty.tty4                                                                                                                 [  started 01:04:33 (0) ]
 agetty.tty3                                                                                                                 [  started 01:04:33 (0) ]
 agetty.tty2                                                                                                                 [  started 01:04:33 (0) ]
 agetty.tty1                                                                                                                 [  started 01:04:33 (0) ]
Dynamic Runlevel: hotplugged
 net.enp5s0                                                                                                                              [  started  ]
Dynamic Runlevel: needed/wanted
 display-manager-setup                                                                                                                   [  started  ]
 dbus                                                                                                                                    [  started  ]
 virtlogd                                                                                                                                [  started  ]
Dynamic Runlevel: manual

I don´t have much time right now to investigate any further. I'll update this topic if I ever find what


Marking this topic as solved.

[papu]

Hello,

I am experiencing a similar case. The cpupower works for me, and it changes from powersave to performance, but what doesn't work for me or what I don't have support for is schedutil, even though I have it set as default in the kernel.

Linux/x86 6.12.9-gentoo Kernel Configuration
-*- CPU Frequency scaling │
│ [ ] CPU frequency transition statistics │
│ Default CPUFreq governor (schedutil) ---> │
│ -*- 'performance' governor │
│ < > 'powersave' governor │
│ <*> 'userspace' governor for userspace frequency scaling │
│ < > 'ondemand' cpufreq policy governor │
│ < > 'conservative' cpufreq governor │
│ -*- 'schedutil' cpufreq policy governor │
│ *** CPU frequency scaling drivers *** │
│ [ ] Intel P state control │
│ <M> Processor Clocking Control interface driver │
│ -*- AMD Processor P-State driver │
│ (3) AMD Processor P-State default mode │
│ <M> selftest for AMD Processor P-State driver │
│ <M> ACPI Processor P-States driver

I also don't understand is why I only have support for performance or powersave, and why powersave is the default in the system if I don't even have it enabled in the kernel. I am a plasma 6 user

~ $ cpupower frequency-info
analyzing CPU 9:
driver: amd-pstate-epp
CPUs which run at the same hardware frequency: 9
CPUs which need to have their frequency coordinated by software: 9
maximum transition latency: Cannot determine or is not supported.
hardware limits: 545 MHz - 5.39 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 545 MHz and 5.39 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 4.26 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
AMD PSTATE Highest Performance: 166. Maximum Frequency: 5.39 GHz.
AMD PSTATE Nominal Performance: 117. Nominal Frequency: 3.80 GHz.
AMD PSTATE Lowest Non-linear Performance: 93. Lowest Non-linear Frequency: 3.02 GHz.
AMD PSTATE Lowest Performance: 13. Lowest Frequency: 545 MHz

[Ralphred]

I also don't understand is why I only have support for performance or powersave, and why powersave is the default in the system if I don't even have it enabled in the kernel. I am a plasma 6 user

~ $ cpupower frequency-info
analyzing CPU 9:
driver: amd-pstate-epp

AMD's pstate driver only supports powersave and performance. There are some nifty switches you can use on the kernel cmdline that will tailor the governors, personally I find just

Code: Select all

amd_pstate=active amd_prefcore=enable

with the powersave governor gives the best result (whilst "active" might sound like a boolean switch, it isn't) << It's the only non "run it at full speed always" governor I've ever found that will run games smoothly, and the the extra thermal overhead from running powersave actually lets the CPU perform better when some cores are idle.

The amd pstate driver was only "fully implemented" in kernel 6.9.1, so check the change logs for it being backported or upgrade to >=6.9.1.

[papu]

I also don't understand is why I only have support for performance or powersave, and why powersave is the default in the system if I don't even have it enabled in the kernel. I am a plasma 6 user

~ $ cpupower frequency-info
analyzing CPU 9:
driver: amd-pstate-epp

AMD's pstate driver only supports powersave and performance. There are some nifty switches you can use on the kernel cmdline that will tailor the governors, personally I find just

Code: Select all

amd_pstate=active amd_prefcore=enable

with the powersave governor gives the best result (whilst "active" might sound like a boolean switch, it isn't) << It's the only non "run it at full speed always" governor I've ever found that will run games smoothly, and the the extra thermal overhead from running powersave actually lets the CPU perform better when some cores are idle.

The amd pstate driver was only "fully implemented" in kernel 6.9.1, so check the change logs for it being backported or upgrade to >=6.9.1.

I forgot to mention my kernel : 6.12.9
I don't understand why is using powersave if itsn't enabled in my kernel, are the cpu drivers independent of kernel CPU Frequency scaling options?
There may still be not no CPU that supports schedutil, may there?

[Goverp]

papu,

FWIW my setup is using AMD p-state=guided with schedutil as governor. That's on an AMD Ryzen 9 5950X, kernel 6.12.9.
My guess is you aren't running the kernel you think you are...

[Ralphred]

I forgot to mention my kernel : 6.12.9

You're all good then, I've only tested 6.9.1 and 6.12.8 < both seem fine

don't understand why is using powersave if itsn't enabled in my kernel, are the cpu drivers independent of kernel CPU Frequency scaling options?

Kind of, from the info in your first post you are running amd-pstate-epp (the best one IME). I think you can use the other drivers if you chose a different operating mode ('guided' IIRC, I only used it once and it wasn't as good as 'active' mode, that was on a zen3 5600X so YMMV)

Don't conflate the epp governors with the "traditional" powersave and performance governors though (where powersave would cap max_freq to under that which the hardware was capable of, and performance would peg all cores at max), they are both more of an "ondemand" governor, one with a preference towards energy efficiency, and one with a preference towards performance.
As I'm writing this now my cpu usage is at about 5%: Using the powersave governor I have cores running between 0.6 and 5.6GHz, with an average of ~2.8GHz, if switch it to performance I get cores running between 0.6 and 5.5, with an average of ~3.2GHz. If I load it up to 100% both governors produce the same result with cores running between 4.8-4.9 with an average of 4.9GHz. The cpu is sold as a 4.4GHz processor, so I'd expect the 100% load numbers to possibly drop as it gets warmer.[/quote]

[papu]

papu,

FWIW my setup is using AMD p-state=guided with schedutil as governor. That's on an AMD Ryzen 9 5950X, kernel 6.12.9.
My guess is you aren't running the kernel you think you are...

ahh, I had to change from 3 to 4 on CONFIG_X86_AMD_PSTATE_DEFAULT_MODE, that is I was looking for.

In your opinion of using schedutil , would more suitable than EPP? I mean if you noticed better performance and so

Are you using cpupower to make it permanent, aren't you?

[papu]

I forgot to mention my kernel : 6.12.9

You're all good then, I've only tested 6.9.1 and 6.12.8 < both seem fine

don't understand why is using powersave if itsn't enabled in my kernel, are the cpu drivers independent of kernel CPU Frequency scaling options?

Kind of, from the info in your first post you are running amd-pstate-epp (the best one IME). I think you can use the other drivers if you chose a different operating mode ('guided' IIRC, I only used it once and it wasn't as good as 'active' mode, that was on a zen3 5600X so YMMV)

Don't conflate the epp governors with the "traditional" powersave and performance governors though (where powersave would cap max_freq to under that which the hardware was capable of, and performance would peg all cores at max), they are both more of an "ondemand" governor, one with a preference towards energy efficiency, and one with a preference towards performance.
As I'm writing this now my cpu usage is at about 5%: Using the powersave governor I have cores running between 0.6 and 5.6GHz, with an average of ~2.8GHz, if switch it to performance I get cores running between 0.6 and 5.5, with an average of ~3.2GHz. If I load it up to 100% both governors produce the same result with cores running between 4.8-4.9 with an average of 4.9GHz. The cpu is sold as a 4.4GHz processor, so I'd expect the 100% load numbers to possibly drop as it gets warmer.

Yep , I had to change to guided instead EPP to use kernel schedutil.

But I don't know how to test the differences between both

# cpupower frequency-info
analyzing CPU 11:
driver: amd-pstate
CPUs which run at the same hardware frequency: 11
CPUs which need to have their frequency coordinated by software: 11
maximum transition latency: 20.0 us
hardware limits: 545 MHz - 5.39 GHz
available cpufreq governors: userspace performance schedutil
current policy: frequency should be within 545 MHz and 5.39 GHz.
The governor "schedutil" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 3.44 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
AMD PSTATE Highest Performance: 171. Maximum Frequency: 5.39 GHz.
AMD PSTATE Nominal Performance: 117. Nominal Frequency: 3.80 GHz.
AMD PSTATE Lowest Non-linear Performance: 93. Lowest Non-linear Frequency: 3.02 GHz.
AMD PSTATE Lowest Performance: 13. Lowest Frequency: 545 MHz.

[Goverp]

...
In your opinion of using schedutil , would more suitable than EPP? I mean if you noticed better performance and so

Are you using cpupower to make it permanent, aren't you?

IIUC pstate-epp is an alternative to pstate, specifically one better for power management on battery-powered devices. The machine I discussed is a desktop - no batteries. pstate-epp is not an alternative to schedutil, it's a collaborator with it, or whichever governor you choose. I believe in general schedutil is recommended over the other governors irrespective of scaling drivers, except in specific cases (for example, I use powersave on my laptop because so many web sites these days seem to rely on Javascript that maxes out my cpus and burns through battery in an hour or less).

As to cpupower, I just used it as the handiest tool to check the driver & governor in use where what I thought they were. My pstate=guided is specified on the command line, and the rest is configured in the kernel; that's all.

As to performance, I haven't bothered with any benchmarks, as my system is fast enough - though the ever-increasing cost of "Mitigations" might make me take more notice at some point!

[papu]

I finally decided to change the default pstate mode to 4 (guided) in kernel and grub using GRUB_CMDLINE_LINUX_DEFAULT="amd_pstate=guided amd_prefcore=enable" moreover prefcore have synergy with SCHED_MC_PRIO=y from kernel.

the question is whether I will be able to notice the difference beyong just the placebo effect

~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
userspace performance schedutil

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

~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
schedutil

[Goverp]

Thanks for mentioning amd_prefcore=enable, which I'd completely missed. Something new to play with.