What are the implications of setting the CPU governor to "performance"?

Question

I recently read that I can eke more performance out of my CPU by setting the governor to "performance" instead of "powersave". According to the Arch wiki, this will "run the CPU at the maximum frequency" instead of the "minimum frequency".

I found this wording confusing, so I also read the kernel documentation.

2.1 Performance

The CPUfreq governor "performance" sets the CPU statically to the highest frequency within the borders of scaling_min_freq and scaling_max_freq.

2.2 Powersave

The CPUfreq governor "powersave" sets the CPU statically to the lowest frequency within the borders of scaling_min_freq and scaling_max_freq.

What does "statically" mean? To me, it contrasts with "dynamic", and implies frequency would never change, i.e. with powersave the CPU frequency would always be a single value, equal to scaling_min_freq. However, this is clearly not the case. I am currently running "powersave" by default. I can monitor the CPU frequencies with

$ watch grep \"cpu MHz\" /proc/cpuinfo

and see them changing dynamically.

What does the kernel documentation mean by "statically"? What factors affect the CPU frequency, and how do these change with "powersave" and "performance"? Hence, what are the implications of changing from the former to the latter? Would a higher frequency be used? During what circumstances? Specifically, will this affect power draw, heat and lifespan of my CPU?

Answer 1

For the record, the (up-to-date) cpufreq documentation is here.

What does "statically" mean?To me, it contrasts with "dynamic", and implies frequency would never change, i.e. with powersave the CPU frequency would always be a single value, equal to scaling_min_freq

You're right. Back in the old cpufreq driver days, there were two kinds of governors: dynamic ones and static ones. The difference was that dynamic governors (ondemand and conservative) could switch between CPU frequencies based on CPU utilization whereas static governors (performance and powersave) would never change the CPU frequency.
However, as you have noticed, with the new driver

this is clearly not the case.

This is because the new driver, which is called intel_pstate, operates differently. The p-states aka operation performance points involve active power management and race to idle which means scaling voltage and frequency. For more details see the official documentation.
As to your actual question,

What are the implications of setting the CPU governor to "performance" ?

it's also answered in the same document. As with all Skylake+ processors, the operating mode of your CPU is - by default - "Active Mode with HWP" so the implications of using the performance governor are (emphasize mine):

HWP + performance

In this configuration intel_pstate will write 0 to the processor’s Energy-Performance Preference (EPP) knob (if supported) or its Energy-Performance Bias (EPB) knob (otherwise), which means that the processor’s internal P-state selection logic is expected to focus entirely on performance,.

This will override the EPP/EPB setting coming from the sysfs interface (see Energy vs Performance Hints below).
Also, in this configuration the range of P-states available to the processor’s internal P-state selection logic is always restricted to the upper boundary (that is, the maximum P-state that the driver is allowed to use).

---

In a nutshell:
intel_pstate is actually a governor and a hardware driver all in one. It supports two policies:

• the performance policy always picks the highest p-state: maximize the performance and then go back down to a virtual zero energy draw state, also called "Race to Idle"
• the powersave policy attempts to balance performance with energy savings: it selects the appropriate p-state based on CPU utilization (load at this specific p-state, will probably go down when going to a higher p-state) and capacity (maximum performance in highest p-state)

Answer 2

In my personal experience, with every computer I've used, "powersave" allows for CPU frequency/voltage scaling and downscales the CPUs at idle by default, whereas "performance" only uses CPU frequency/voltage scaling when it needs to, e.g., when the processor's operation exceeds the thermal envelope.

I also have a question of whether disabling frequency scaling also has the same impact as changing the governor from "powersave" to "performance" mode, or whether those governors also change some additional logic parameters other than scaling that would also affect performance. For example, it would seem that under "performance" governor, "minimum" frequency threshold is ignored, and the CPU automatically jumps to highest available frequency within its thermal envelope. So it would appear that there is no functional difference between changing the frequency governor and simply setting "min/max frequency" to its highest values.

To test this, I installed HardInfo 0.6-alpha and ran through multiple instances of all performance tests using each of the three following settings:

1. Governor: Performance, max and min cpu frequency both set at max
2. Governor: Performance, max cpu frequency at max, min frequency at min
3. Governor: Powersave, max and min cpu frequency both set at max

I could not see any consistent deviations in performance between these three settings outside the margin of error. Someone with more experience testing might be able to do a more thorough job testing for differences between these performance settings. But for practical purposes, they appear to be analogous. So then the main issue becomes streamlining CPU control UI to eliminate any unnecessary complexity. Changing the pstate governor from powersave to performance appears redundant to simply locking the min/max frequencies together.

For specialized computing systems, it is easier just to leave a CPU at "performance" governor to match its specialized workload, but for multi-use workstations, it may make more sense to leave the governor on powersave and rather adjust performance through the min/max settings to give users more fine-grained control over specific performance scenarios.

Answer 3

I'm not sure what page you're reading, but the page CPU frequency scaling on wiki.archlinux mentions that:

Since kernel 3.4 the necessary modules are loaded automatically and the recommended ondemand governor is enabled by default.

The ondemand governor increases the CPU speed when there's enough load on the system to benefit from an increased speed, i.e. there's something running on the CPU for a full time slot.

Check the governor you're running to see if it's indeed ondemand, (/sys/devices/system/cpu/cpufreq/policyN/scaling_governor) there's probably no need to change it from that default.

performance and powersave indeed seem to set the frequency directly to the maximum and minimum (respectively), and will not change it depending on the load.

---

Except that the wiki page also mentions that performance takes the role of ondemand on Sandy Bridge systems and later. It's also the default on those machines. So, come to think of it, if your system is new enough, you might be seeing that in action. Check the link to an article discussing this on the wiki.