Difference between revisions of "Talk:CPU frequency scaling"

From ArchWiki
Jump to navigation Jump to search
 
(14 intermediate revisions by 4 users not shown)
Line 31: Line 31:
 
== Pstate governor; disabling turbo boost: using 'wrmsr' utility from msr-tools as echoing wouldn't do squat ==
 
== Pstate governor; disabling turbo boost: using 'wrmsr' utility from msr-tools as echoing wouldn't do squat ==
  
In my case echoing {{ic|/sys/devices/system/cpu/intel_pstate/no_turbo}} did not work. I had to use appropriate {{ic|wrmr}} command on each individual core to disable it. More info [https://askubuntu.com/a/619881 here]. You think it's worth mention?
+
In my case echoing {{ic|/sys/devices/system/cpu/intel_pstate/no_turbo}} did not work. I had to use appropriate {{ic|wrmr}} command on each individual core to disable it. More info [https://askubuntu.com/a/619881 here]. You think it's worth mention? -- [[User:Soocki|Soocki]] ([[User talk:Soocki|talk]]) 10:15, 15 November 2018 (UTC)
  
--[[User:Soocki|Soocki]] ([[User talk:Soocki|talk]]) 10:15, 15 November 2018 (UTC)
+
:Which CPU do you have? What error did you get when trying the echo command? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:19, 15 November 2018 (UTC)
 +
 
 +
::I was able to echo the file but it did not disable turbo (as reported by {{ic|i7z}} and {{ic|cpupower}}). CPU is i7-4710MQ on a t440p Thinkpad. -- [[User:Soocki|Soocki]] ([[User talk: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 {{ic|/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq}} changes after echo. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:06, 16 November 2018 (UTC)
 +
 
 +
::::As far as I can tell echoing had no impact on CPU's temperature and {{ic|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? --[[User:Soocki|Soocki]] ([[User talk: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/v4.12/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.
 +
 
 +
{{unsigned|22:48, 21 November 2018‎|Sangeppato}}
 +
 
 +
: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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:06, 22 November 2018 (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). [[User:Randomstring|Randomstring]] ([[User talk: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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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"). [[User:Randomstring|Randomstring]] ([[User talk: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. [[User:Randomstring|Randomstring]] ([[User talk: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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:47, 7 November 2019 (UTC)
 +
 
 +
:::::: Sorry... I apologize for my brainfart. I just mixed up the names. [[User:Randomstring|Randomstring]] ([[User talk:Randomstring|talk]]) 19:59, 7 November 2019 (UTC)

Latest revision as of 19:59, 7 November 2019

CPU frequency driver

"Note: As of kernel 3.4; the native cpu module is loaded automatically"

I tested today in my netbook with Atom 330 with kernel 3.7 [testing]. the autoload module not working (after edit modules-load.d and reboot)

this still workinkg?

greetings

-- Sl1pkn07 (talk) 16:00, 21 January 2013 (UTC)

Worked for me now. More than 4 years after the Sl1pkn07's post. Most probably with other setup then his. Regid (talk) 22:27, 17 March 2017 (UTC)

Intel Sandybridge and higher CPU governors

Long story

Short story

Sandybridge+ CPUs use specific Intel driver that has 2 governors: powersave (default) and performance. If you wish to use another governor, you need to disable this driver (more in the link above).Tharbad (talk) 15:55, 8 March 2016 (UTC)

Thermald and Haswell CPU's

Should probably mention that thermald doesn't fully work with Haswell CPU's?

See: https://github.com/intel/thermal_daemon/issues/135 Also: https://github.com/intel/thermal_daemon/issues/82

—This unsigned comment is by Utini2000 (talk) 13:55, 9 August 2017‎. Please sign your posts with ~~~~!

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/v4.12/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)
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)