Intel_pstate & power governor default explained

FAQ and Tutorials
1

This is just a notice to everyone searching for things like “why is my computer always booting in powersave / power save mode?”

I had the same “problem” going on with my computer, but finally found a single line that explains why that is expected behavior if you have an Intel CPU/processor using the intel_pstate driver.

So when I started this journey, I initially noticed a message showing up in the journal during boot:
ENERGY_PERF_BIAS: Set to 'normal', was 'performance'

Normal? But I had set the power profile in KDE to performance if it was on AC (and it is). Why is it changing to normal?

performance_kde

Now, if I install cpupower and set it to performance mode (or via sysfs similar to below), it still changes the energy performance bias to performance. On kernels older than 5.18, I do notice a slight improvement by changing this value manually (or automatically via a script, but doesn’t seem to auto-change based on power state).

>>> cat /sys/devices/system/cpu/cpu*/power/energy_perf_bias
File: /sys/devices/system/cpu/cpu0/power/energy_perf_bias
6
...

A value of 6 is normal, lower values down to 0 goes to performance, and higher values are for powersave. 6 appears to be the default.

I then discovered other values like scaling governor.

>>> cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
File: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
...

Powersave? I thought it should be performance?

After digging around the internet and seeing most documentation pointing to tlp refering to what values this could be (and noting that intel_pstate only has the values powersave and performance available). However, tlp is not installed by default and isn’t anymore. It provides roughly the same function as power-profiles-daemon, but the latter is required for KDE’s power settings to work. You can’t have both installed, they conflict.

So I went to the power-profiles-daemon gitlab page.

Partway down the page under the “Operations on Intel-based machines” heading, there is a small paragraph:

Finally, if the Intel P-State scaling driver is used in active mode, the P-State scaling governor will be changed to powersave as it is the only P-State scaling governor that allows for the “Energy vs Performance Hints” to be taken into consideration, ie. the only P-State scaling governor that allows power-profiles-daemon to work.

So the CPU governor value is expected to be powersave if you have the intel_pstate driver as it’s the only one that will work properly with the power profile daemon. When I change it to performance manually I notice some strange stuttering happening.

As far as the other stuff… I suppose the ENERGY_PERF_BIAS value largely has little effect when intel_pstate driver is used.

If you want to see what power profile daemon is set to, you can use powerprofilesctl:

>>> powerprofilesctl
* performance:
Driver:     intel_pstate
Degraded:   no

balanced:
Driver:     intel_pstate

power-saver:
Driver:     intel_pstate

The asterisk (*) is the one that is currently in use, so clearly it is set to performance which is what I expect… even if the other values for /sys/devices/system/cpu/cpu*/ are not what you would expect.

TLDR: The driver seems to ignore some hinting values and requires the governor to be powersave to work properly with the software performance hinting libraries, so you don’t need to worry about those.

4 Likes
2

After reading through the documentation for the intel_pstate drivers, I discovered the actual sysfs parameter that determines the performance bias that would be used (link below). Essentially, this is the value that would be used in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor on systems that use the acpi_cpufreq driver instead of intel_pstate. This is likely what power-profiles-daemon is setting when you change the value via the GUI.

>>> cat /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference
File: /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference
performance
...

https://www.kernel.org/doc/html/v4.19/admin-guide/pm/intel_pstate.html#energy-vs-performance-hints

3 
sudo systemctl enable cpupower && sudo systemctl start cpupower
sudo cpupower frequency-set -g performance

That's what I do in a vanilla Arch installation. But not Garuda.

These settings work just fine UNLESS I institute Garuda's own powersaving/performance settings. Why? Garuda uses its own procedures, applications, and settings. Their settings are worth exploring and so "in your face" I don't know how anyone could miss them.

Really--everyone. If You are going to take the time to explore Garuda, then do so. sigh

1 Like
4

I tested cpupower prior to kernal 5.18 and it did have a small impact, I believe it’s using the same hints that power-profiles-daemon does, so it’s shouldn’t make much of a difference. It’s also entirely manual. So if you have a laptop and go from AC to battery power, it won’t change settings unless you change them (unlike using KDE settings where you can set what to hint for AC, battery, and low battery)… or you set up your own automated scripts.

Granted, power-profiles-daemon is used by KDE. If you’re using a different front-end it may not have build-in performance profile settings so you may need to use your own hinting software or scripts.

As far as Garuda’s tweaks, they don’t really have to do with performance hinting directly. They use various pieces of software to manage other aspects such as optimizing CPU interrupts, managing application memory use, and prefetching algorithms. I’m sure using both performance hints along with Garuda’s tweaks do have a greater impact on power usage.

5

Was it quantifiable or did it just feel that way?

That may be true. I run solely Plasma in Linux nowadays, and it has made great strides towards creating a smaller, faster impact on working memory. But here’s something to note…

A vanilla Arch + KDE installation, fully-fledged, boots into Plasma very fast on this 2019 9th Gen desktop machine. I subsequently install cpupower & x86_energy_perf_policy, and preload plus profile-sync-daemon from the AUR. Configuration as-needed. And I install/use ZRAM and an OOM manager.

I get the feeling that I don’t need any or most of it. Because, like I said, it boots and loads very fast as-is. Several of those items are done just because that’s what I may have needed to do with prior machines, and one thing just builds upon the other. I do some by rota, needed or not.

However. Garuda (dr460nized) leaves me with the feeling all those things are taken care of–mostly because they are. I’m not going to try to quantify that statement. It’s just the way it feels to me after clicking all the related settings and rebooting and using, and that’s non-judgmental. Garuda specifics and improvements can be found in things modprobe and udev related settings, and other post-installation tweaks it takes experienced Archers time to implement. Garuda’s developers have thought of most or all of those things. It isn’t just installing a few tweakable packages.

1 Like
6

I didn’t run any benchmarks, but I would notice this slight visual stuttering/jumping at times. After setting cpupower to performance the stuttering disappeared. However, it no longer is an issue as the stuttering no longer happens in 5.18.

Probably not, some of that likely overlaps in what it does and performance enhancements added to the kernel, drivers, and software often render those tweaks less effective over time.

Some of the packages you listed are already installed by Garuda either by default or through some tweaking settings.

I will. I first started using Linux for work and on-and-off trying it out as a desktop at home back in the early 2000s. Back then it worked, but there were a lot of missing drivers and other issues. Getting a lot of hardware to work was a major pain and took many hours to get a stable desktop working. I then tried it again 10 years ago and noticed a fairly big improvement (part of which was due to various standards emerging that meant manufacturer-specific drivers were no longer required). What before took 6+ hours to get working now took 2. I then started installing it again a couple years ago and was initially hit by some major performance issues that didn’t make sense. Certain distributions wouldn’t even boot when I tried them. However, outside of the performance issue, everything else worked perfectly fine with minimal need to install anything extra. I since found out a lot of the performance issue was due to the machines I was using being geared for Windows rather than Linux, however in a very short amount of time, most of those issues are now gone through kernel and software updates. Garuda has been the best performing distro I’ve used and think that Linux desktop in general has come a long way. I use it as my everyday desktop now and since 5.18 emerged I have it running extremely stable and performance is on-par with Windows.

7

It helps there are more developers now, hence more personal itches get satisfied to the benefit of all. Considering I blew-up a monitor trying–unsuccessfully–to set a scan rate while installing Linux when the kernel hit stable 1.0, “long way” might be considered an understatement. For a time my Linux experiments had to remain sub-rosa to avoid the ire of an “I’m not buying you another monitor” wife. She says its all part of my history of doing bad things to good hardware.
:wink: :rofl:

4 Likes
8

" pstate-frequency doesn't work

Sometimes you will notice that even when a frequency is requested using pstate-frequency, the CPU will still run at higher, or lower frequencies. This is explained by the kernel documentation snippet below:

For contemporary Intel processors, the frequency is controlled by the processor itself and the P-states exposed to software are related to performance levels. The idea that frequency can be set to a single frequency is fiction for Intel Core processors. Even if the scaling driver selects a single P state the actual frequency the processor will run at is selected by the processor itself.

This means that although a certain value may be requested through the pstate-frequency software interface, the actual frequency that the CPU will run at is decided solely by the hardware itself. pstate-frequency is only able to offer "suggestions" as to what frequency should be run, not make strict rules."

2 Likes