Talk:CPU frequency scaling

From ArchWiki
Jump to navigation Jump to search

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?


-- 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: Also:

—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 ( 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)

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 ~~~~!

"Make changes permanent" section uses an undocumented tmpfiles.d directive

The example uses a `w-` directive that isn't documented in the tmpfiles.d manpage. Please explain what exactly it does. —This unsigned comment is by Rulatir (talk) 15:43, 15 August 2021 (UTC). Please sign your posts with ~~~~!

An example using w- is present in tmpfiles.d(5) § Type, in particular:
If the minus sign ("-") is used, this line failing to run successfully during create (and only create) will not cause the execution of systemd-tmpfiles to return an error.
For example:
# Modify sysfs but don't fail if we are in a container with a read-only /proc
w- /proc/sys/vm/swappiness - - - - 10
-- Flyingpig (talk) 15:55, 15 August 2021 (UTC)


Thermald should also work with AMD. Pickfire (talk) 02:46, 23 September 2021 (UTC)