Option to change Policy (Powersave-Performance)

[Sangeppato]

With Intel P-state, if I've undestood correctly, there are not real scaling governor anymore, but we can still set the "policy" of the processor choosing between powersave and performance (for example running "cpupower frequency-set -g powersave/performance"). Would it be possible to implement the option to select this policy within the extension?

[martin31821]

The pstate driver can operate in different modes, for a detailed description you can read up here: https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html

The governors you mentioned are only available when you add intel_pstate=no_hwp to your kernel command line which means effectively disabling the cpu's internal frequency selection logic and power gating.

I personally don't use this setting because I think, the CPU knows best which cores it should clock at which frequency and how it is managing the power state and gating.

Feel free to submit a PR if you like, but I'd like to make sure that this option is only visible/usable when the respective kernel argument is set.

[Sangeppato]

Thanks for the response, actually even without the "intel_pstate=no_hwp" kernel parameter I can still apply the Performance policy with cpupower and see the frequency going up and sticking to the maximum (it doesn't scale), but maybe I'm not getting entirely how the pstate driver works. I make music on my laptop, so I'm trying to get a realtime system and it looks like the Performance policy should help, but I have to say that I'm quite confused with how HWP works. If I manually set both the minimum and maximum frequency at 100%, should I get the same result as selecting the Performance policy (basically selecting the highest P-state) or is there something else like voltage?

[martin31821]

You're right, I have this setting on my notebook as well and it seems to change something rgd the behavior.

If you set 100% minimum and 100% maximum then your core will be at full speed (Core voltage will be adjusted automatically) (Disclaimer: I don't think that's a good idea unless you have very good cooling).

TBH: Music applications are basically idle load for modern CPUs, the amount of data to be processed is fairly small. I think you should experiment with other tweaks, like niceness and RT patches...

Nevertheless, I'll keep it as feature request.

[Sangeppato]

Thanks, I really appreciate it!

Regarding the Audio topic: I had already applied all the patches suggested on the Arch Wiki and the situation didn't improve much. It's impossible to get low latency without pinning the cpu at high frequency (Consider that the buffer size in ALSA should me at maximum 256, better if 128 or below) and even on macOS (arguably the best OS around for music production) this happens.

EDIT: Anyway I'm manually pinning the cpu at 100% at both minimum and maximum (basically what the performance policy does) and the temperature is not bad at all, it stays at about 50 degrees on a crappy laptop. It looks like without a heavy load, the frequancy alone doesn't make such a huge impact on temperature, even if I don't understand why.

[Sangeppato]

Having a more accurate look at the kernel documentation here, it looks like selecting the "Performance" policy should be just the same as setting both the minimum maximum frequencies at the same level :

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).

So in both cases the CPU will use the highest P-state available (I think).

[ayoungethan]

So in both cases the CPU will use the highest P-state available (I think).

I did some cursory benchmarking of exactly this question a few weeks ago and found ABSOLUTELY ZERO MEANINGFUL DIFFERENCE between EPP "performance" and simply locking "min/max" at the highest frequency. The driver automatically throttles based on thermal stress either way, to protect the thermal integrity of the hardware. https://pop-planet.info/forums/threads/power-management-design-interface.739/

So it would appear, for example, that the "indicator-cpufreq" extension, for example, is now completely redundant to the more flexible CPU Power extension, which provides much greater control over performance.

[bjeanes]

I find a very huge difference between the two governors, even when min/max is unchanged between them. My laptop will adjust clocks down to around 800Mhz when idle on powersave governor (but still ramp it up as needed). powersave even with the same min setting will stay in the 2-3GHz range more often.

Being able to change the governor in profiles would be a welcome improvement. Currently, I'm having to manually switch governor when I am on battery if I want to get the most out of my battery life. It makes a huge difference. Without changing the governor I would need to limit the max heavily but then I lose out on performance during peak workloads. Based on my observations and lots of experimenting over the last 24 hours, the governor has a LARGE impact on where within the min-max range the frequency is biased towards.

Being able to also have an Auto Switch configuration based on battery % would make it perfect but could also be out of scope.

[bjeanes]

On my laptop right now, with the performance governor, the avg freq across all 8 cores is floating around 4.3-4.55GHz (but very occasionally floating down as low as 2.8Ghz):

If I do nothing other than change the governor to powersave (not touching min or max), it biases towards around 800Mhz and comfortably ranges up to 2Ghz for brief peaks and up to 3.8ish (when kicking off a compile in the background -- though I only caught 3.5 in the screenshot):

During both of those governor options, the min and max were unchanged:

❯ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
100
❯ cat /sys/devices/system/cpu/intel_pstate/min_perf_pct
8

However, changing /sys/devices/system/cpu/intel_pstate/min_perf_pct didn't seem to have any effect, so perhaps these files are not honoured in the way I thought they were...

[cdegroot]

I think that this discussion went a bit off-track. Allow me to recap what I understand from the docs:

• There are two "governors" with intel_pstate that are confusingly named after existing governors, but any similarity in naming is pure coincidence.
• The "performance" governor instructs the on-CPU power management to forego trying to save the planet (per the docs, it'll write "0" to the processors power preference/bias register, meaning "floor it");
• The "powersave" governor writes whatever is configured for power management to the register. In the policyX directory, the energy_performance_preference file represents the string value of this integer value and the energy_performance_available_preferences the available values, which are either default (whatever the BIOS says) and - on my 10th gen CPU - performance, balance_performance, balance_power, power - a scale of "tune for performance" to "tune for powersave".

That's my read from the docs. Now let's assume I'm right :)

I do think that you want to be able to set that, and not just the frequency scaling (or, with intel_pstate, as P-state limits, because as far as I know everything "frequency" gets translated to p-states) because it will affect how your computer responds to load requrements, and to me that is in the realm of what the extension tries to control.

Now note that we have one main switch and one "sub switch" that is only enabled if the main switch (named "governor") goes from "performance" (correct name) to "powersave" (wrong name). I'm quite sure that the "performance" governor (EPP=0) is the same as the "powersave" governor with energy_power_preference=performance. So the extension could get away with just putting the governor always to powersave and then let the user select the energy performance preference in the profiles or ad hoc.

[mhagnumdw]

Any news here?

[aceqbaceq]

+1