Talk:CPU frequency scaling

Pstate governor; disabling turbo boost: using 'wrmsr' utility from msr-tools as echoing wouldn't do squat

In my case echoing /sys/devices/system/cpu/intel_pstate/no_turbo did not work. I had to use appropriate wrmr command on each individual core to disable it. More info here. You think it's worth mention? -- Soocki (talk) 10:15, 15 November 2018 (UTC)

Which CPU do you have? What error did you get when trying the echo command? -- Lahwaacz (talk) 17:19, 15 November 2018 (UTC)

I was able to echo the file but it did not disable turbo (as reported by i7z and cpupower). CPU is i7-4710MQ on a t440p Thinkpad. -- Soocki (talk) 23:29, 15 November 2018 (UTC)

I also get "TURBO ENABLED" reported in i7z after disabling turbo with echo, but the frequency does not go above the base frequency. Also the value in /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq changes after echo. -- Lahwaacz (talk) 07:06, 16 November 2018 (UTC)

As far as I can tell echoing had no impact on CPU's temperature and wrmr greatly reduced it. Also utilities started reporting turbo as disabled. If turbo is reported enabled doesn't that indicate it is infact enabled? Maybe someone can try to confirm my observations? --Soocki (talk) 07:51, 16 November 2018 (UTC)

Intel Pstate "Performance" governor

In the wiki it's declared that: "The intel_pstate driver supports only the performance and powersave governors, but they both provide dynamic scaling. The performance governor should give better power saving functionality than the old ondemand governor".

On all my systems (all with the intel pstate driver) if I set the governor to "Performance", the CPU frequency will be pinned at the highest possible value, it doesn't scale at all. Looking at the kernel documentation here (https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html) it's said, referred to the performance governor: "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)". I think that, since we cannot control directly the frequency anymore, but only the P-state, this means that this governor is not supposed to scale the frequency, but to keep the highest possible value (which by the way can be adjusted by the user, setting the max freq), similarly to the old one.

—This unsigned comment is by Sangeppato (talk) 22:48, 21 November 2018‎. Please sign your posts with ~~~~!

That's not what happens in my case (Xeon CPU E5-1620 v4). Your quote talks about a range of P-states, which implies that the driver is still scaling. -- Lahwaacz (talk) 08:06, 22 November 2018 (UTC)

A missed point here is difference between HWP and non-HWP modes. Sandy Bridge and above has HWP, so the system communicates a preference for auto-scaling via the EPP/EPB; older ones do not and the kernel doc states "highest P-state". --Arthur2e5 10:07, 4 June 2023 (UTC)

Agreed, "performance" does not scale down well for me and should not be recommended for power saving at this time (kernel 5.3.8). Randomstring (talk) 12:16, 6 November 2019 (UTC)

The note in CPU frequency scaling#Scaling governors does not recommend to use "performance" over "powersave", it merely compares the pstate's "performance" governor with the cpufreq's "ondemand" governor. -- Lahwaacz (talk) 13:24, 6 November 2019 (UTC)

You're strictly correct that it doesn't recommend it, but it strongly suggests "performance" will prolong battery life vs "powersave". In my experience this isn't true at all, unless I'm missing a configuration step that is not explained in the Wiki. One single informal conversation between kernel hackers does not trump all the other sources, including TLP, that use "powersave" to save on power. I absent mindedly enabled "performance" on faith and got abysmal battery life. Fortunately I reminded myself to verify cpu frequency behaviour and it wasn't scaling down well at all (as one would would expect for something named "performance"). Randomstring (talk) 13:23, 7 November 2019 (UTC)

You can argue that it is still relevant information and I won't disagree. It should be presented differently and with some reservations IMO. Randomstring (talk) 13:30, 7 November 2019 (UTC)

The first sentence in the note, i.e. "The intel_pstate driver supports only the performance and powersave governors, but they both provide dynamic scaling.", merely points out that only 2 of the governors listed in the table are applicable and that "performance - Run the CPU at the maximum frequency." is strictly not true for the pstate driver. This part of the note does not even remotely suggest anything about the behaviour of the performance governor vs the powersave governor. The second sentence, i.e. "The performance governor should give better power saving functionality than the old ondemand governor.", does not even contain the word "powersave", it compares "performance" with "ondemand" (cf. the emphasis). So I fail to see how you came up with your conclusion. -- Lahwaacz (talk) 19:47, 7 November 2019 (UTC)

Sorry... I apologize for my brainfart. I just mixed up the names. Randomstring (talk) 19:59, 7 November 2019 (UTC)

intel_pstate is not a module, do not list as a module in module table

As I was trying to use the cpupower program, and being that I have a Sandy Bridge processor, I was trying to load intel_pstate as listed in the module table in CPU_frequency_scaling#CPU_frequency_driver. Only after some time, by reading the big, shouting note above, I found out that intel_pstate is not a module. My question is then: why include it in the module table? Does anybody oppose removing from this table elements that are not actually modules?

—This unsigned comment is by Severoraz (talk) 11:07, 8 May 2021‎. Please sign your posts with ~~~~!

AMD

Thermald should also work with AMD. https://github.com/intel/thermal_daemon/issues/209 Pickfire (talk) 02:46, 23 September 2021 (UTC)

Mentioning power-profiles-daemon

[Moved from Talk:Power management#Mentioning power-profiles-daemon. -- Flyingpig (talk) 00:02, 30 November 2021 (UTC)]

There is the new https://gitlab.freedesktop.org/upower/power-profiles-daemon that works with KDE's and Gnome's power managers and configuration UIs. The package is in https://archlinux.org/packages/extra/x86_64/power-profiles-daemon/. A mention, I think, should be in the userspace tools section. Moreover, what do you think about mentioning something like a couple udev rules to change it automatically on plug/unplug events? I have one written and working. Or maybe a new Wiki section for power-profiles-daemon would be worth? --Icar (talk) 11:01, 21 October 2021 (UTC)

Just dropping by to mention the Template:Move in GNOME#Power modes. Since this aforementioned section already has some content and is related to CPU frequency scaling, I'm thinking that a Template:App for power-profiles-daemon in Power management#Userspace tools, where the first argument is a link to a more detailed section in "CPU frequency scaling", will suffice.

I believe power-profiles-daemon can be used independently of a desktop environment since it comes with the powerprofilesctl command, so its Template:App might also be more suitable under Power management#Console.

I'll move forward with the changes proposed just above (in a week) if there isn't any further input or objections.

-- Flyingpig (talk) 23:45, 19 November 2021 (UTC)

I changed my mind about Power management#Userspace tools and made power-profiles-daemon under CPU frequency scaling#Userspace tools instead. Changes have been made so that GNOME#Power modes and KDE#Power management link to power-profiles-daemon (see Diff/702035/703862, Diff/703861, and Diff/701417/703864) -- Flyingpig (talk) 01:28, 30 November 2021 (UTC)

Regarding udev rules for plug/unplug events: I think KDE may already have profile switching on plug/unplug events by default based on https://pointieststick.com/2021/07/23/this-week-in-kde-power-profiles-and-a-more-polished-kickoff/, so I think this is also something that should be mentioned. GNOME doesn't change power profiles on plug/unplug events (as of writing), so I think including some udev rules might be a good idea. -- Flyingpig (talk) 01:28, 30 November 2021 (UTC)

hwp_dynamic_boost for intel pstates seems to be missing entirely

There's a flag you can enable [1] for the Intel pstates driver (if the hardware supports it). It will raise the minimum CPU limit if there's IO happening, to speed up the performance. I think that's worth mentioning. --RubenKelevra (talk) 18:16, 17 April 2022 (UTC)

The whole intel_pstate section needs a lot of work. I started a rewrite a few months ago, but that's been shelved for now.

hwp_dynamic_boost controls frequency boosting. It should be documented in CPU_frequency_scaling#Configuring_frequency_boosting, and assume that "active mode" is well defined elsewhere in the article (even though it's not, at the moment). It should also be clear what its relationship to no_turbo is. Cheers, CodingKoopa (talk) 02:10, 21 April 2022 (UTC)

Thermald changes persistence

So, ever since I got this Tiger Lake laptop and after I found out that, to fully unlock it's thermal potential I had to install thermald, I noticed that the changes it makes seem to persist even if you disable and stop it, and across poweroffs and reboots. Can somebody else confirm that? However, if you change on the BIOS the profile to powersave, it goes back to what it was and you have to start thermald again to unlock the CPU full speed again. Also, I've spent a lot of time on dell forums and it looks like that intel, starting with 10th generation (Comet Lake), stopped allowing raw temperature readings. Also, it looks like you can't undervolt it anymore, but I haven't fully confirmed it yet. The only way to manage you processor speed now is through TDP, and it seems only Intel's thermald can do that at the moment. Would be like if someone else could also confirm this. This doesn't seem to be specific to Dell. Grazzolini (talk) 13:38, 14 August 2022 (UTC)

About scaling governor while using P-State

The page says:

> The most important feature of active governing is that only two governors appear available, powersave and performance. They do not work at all like their normal counterpart, however: these levels are translated into an Energy Performance Preference hint for the CPU's internal governor.

However, this isn't the behavior I get, it seems that these pseudo-governors only have one difference:

• When the pseudo-governor is set to powersave, you can change the EPP to any value.
• When the pseudo-governor is set to performance, you can change the EPP only to performance (with anything else, you get Device or resource busy).

The source code of power-profiles-daemon seems to confirm that:

• https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/blob/main/src/ppd-driver-intel-pstate.c#L17
• https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/blob/main/src/ppd-driver-amd-pstate.c#L17

Discussion on https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/merge_requests/121

—This unsigned comment is by SuperSamus (talk) 21:01, 27 September 2023. Please sign your posts with ~~~~!

Note about thinkpad_acpi

Before applying the recommendations of section 8.1, if you are using a ThinkPad, be aware that recent models have a sensor that detects if the laptop is being used on the lap or on a desk, and the thinkpad_acpi driver will automatically adjust the platform profile, which could result in a limitation of the clock frequency. The status of the sensor can be checked by reading the file /sys/devices/platform/thinkpad_acpi/dytc_lapmode (1=on lap). It can be useful to check the surface on which your laptop is placed before playing with MSR/MCHBAR registers ;)

Singeinfini (talk) 16:11, 20 January 2024 (UTC)!

Warning, this is very experimental and a little bit hacky: thinkpad-acpi-disable-lapmode.patch Once this patch is installed you can execute echo 0 > /sys/devices/platform/thinkpad_acpi/dytc_lapmod which will disable lap mode and should immediately revert to your previous scheduling policy. If you don't have the luxury of compiling your own kernel, it is possible to achieve the same thing using acpi_call, for instance echo '\_SB.PCI0.LPCB.EC.HKEY.DYTC 0x000F1001' > /proc/acpi/call. I haven't found this documented elsewhere.

Singeinfini (talk) 01:50, 21 January 2024 (UTC)

Persisting settings

There is no mention of how to persist the mentioned settings about frequency scaling. Should one use a daemon to do it at startup? Siavoshkc (talk) 06:02, 21 June 2024 (UTC)