Difference between revisions of "Talk:CPU frequency scaling"

From ArchWiki
Jump to navigation Jump to search
Line 19: Line 19:
 
===Short 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).[[User:Tharbad|Tharbad]] ([[User talk:Tharbad|talk]]) 15:55, 8 March 2016 (UTC)
 
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).[[User:Tharbad|Tharbad]] ([[User talk:Tharbad|talk]]) 15:55, 8 March 2016 (UTC)
 
== <s>Will systemd#Temporary files work to make changes permanent?</s> ==
 
 
[[CPU frequency scaling#Make changes permanent]] firmly suggests to use [[systemd#Temporary files]]. It says it is easiest to use in order to make changes permanent. In fact, it shows an explicit example, and doesn't mention other methods. In contrast, [[systemd#Temporary files]] states, and explains, why this method may not work to set options in {{ic|/sys}} when kernel modules are involved. Did I get it wrong? [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 23:06, 17 March 2017 (UTC)
 
 
:No, good question if it applies to cpu modules (cpu govenors are loaded really early). It sure is simpler, because otherwise you need to figure the correct module for a {{ic|/etc/modprobe.d}} rule first. If no-one has a definite answer regarding {{ic|/sys}} here in due course, my suggestion would be we simply point to the note in [[systemd#Temporary files]] for alternatives in case it does not work. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:05, 18 March 2017 (UTC)
 
 
::If I'm not mistaken the {{ic|cpufreq}} modules don't have any options that could be set by modprobe. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:15, 18 March 2017 (UTC)
 
 
::: Pewrhaps the following is a better method:
 
::: To have changes persist on system reboot probably the paved road is  [[Kernel modules#Using files in /etc/modprobe.d/]]. For example, to set the sampling_down_factor on boot, assuming, for the sake of this example, the CPU frequency driver is {{ic|acpi_cpufreq}}, you could create or edit a {{ic|/etc/modprobe.d/cpu-sampling-down.conf}} file as follow:
 
{{hc|/etc/modprobe.d/cpu-sampling-down.conf|<nowiki>
 
install acpi_cpufreq \
 
echo 40 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor \
 
/sbin/modprobe --ignore-install acpi-cpufreq $CMDLINE_OPTS
 
</nowiki>}}
 
::: {{Note|If any of the affected modules is loaded from the initramfs, you will need to add the appropriate {{ic|.conf}} file to {{ic|FILES}} in [[mkinitcpio.conf]] or use the {{ic|modconf}} [[Mkinitcpio.conf#HOOKS|hook]], so that it will be included in the initramfs. To see the contents of the default initramfs use {{ic|lsinitcpio /boot/initramfs-linux.img}}.}}
 
 
::: {{unsigned| 07:10, 19 March 2017‎|Regid}}
 
 
:::: Hm, good call; yet for me it would be a little too hackish. My own solution for it, given it does not matter when it runs, would be to add it to a late run custom service, which is run anyway to apply various {{ic|/sys}} quirks (powersaving etc). I've googled again and first I saw that [https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html systemd] explicitly mentions {{ic|/sys}} without reservations. Then, [http://unix.stackexchange.com/questions/61159/how-does-systemd-tmpfiles-work stackexchange] has a lot info, including [https://lists.freedesktop.org/archives/systemd-devel/2012-September/006576.html]. Perhaps our systemd note about {{ic|/sys}} problems is just outdated? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:09, 19 March 2017 (UTC)
 
 
:::::My earlier modprobe.d suggestion doesn't work when the managing module, acpi_cpufreq in that example, cuases the creation of the /sys interface. /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor in the example. The following might work:
 
{{hc|/etc/modprobe.d/cpu-sampling-down.conf|<nowiki>
 
install acpi_cpufreq /sbin/modprobe --ignore-install acpi_cpufreq $CMDLINE_OPTS; \
 
echo 40 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
 
</nowiki>}}
 
::::: As my actual case doesn't use cpu-sampling-down, I can't test that specific example. I used it in the first place in an attempt to follow the article example. This is why I also have hard time commenting on [[User:Indigo|Indigo]] comment above. I do believe {{ic|modprobe.d}} is the way to go becuase it looks to me more natural when modules are involved, and less complicated. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 05:19, 20 March 2017 (UTC)
 
 
::::::Your command assumes that the {{ic|/sys/}} entry is available immediately after modprobe exits. From what I know modprobe just loads the binary to the kernel, but the module initialization is done by the kernel and modprobe does not wait until it is finished. So to be 100% sure you would have to execute {{ic|/sbin/modprobe --ignore-install acpi_cpufreq $CMDLINE_OPTS; sleep 1; echo 40 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor}} but that's just a hack no better than using systemd-tmpfiles. Since cpufreq is a module for the CPU, I'd say it is safe to assume that the module is loaded far before systemd-tmpfiles is run on startup and the changes to sysfs are reflected fast enough for the writes from systemd-tmpfiles to work. If you don't like it and want the 100% guarantee of success, I think you should really use udev - there is probably no other way. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:15, 20 March 2017 (UTC)
 
 
:::::::I have no time to pursue it further right now, and my case is somewhat different than the example discussed so far. Hopefully, the short solution at  [http://stackoverflow.com/questions/40673336/using-udev-rules-create-and-remove-device-node-on-a-kernel-module-load-and-unloa stackoverflow], which is only half year old, is our final station.
 
{{hc|/etc/udev/rules.d/50-cpu-sampling-down.rules|<nowiki>
 
SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+="/bin/sh -c 'echo 40 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor'"</nowiki>}}
 
::::::: It is probably should be added to the initramfs.
 
::::::: Is it agreed to edit the article accordingly?
 
:::::::[[User:Regid|Regid]] ([[User talk:Regid|talk]]) 01:49, 21 March 2017 (UTC)
 
 
::::::::Hi, fine with me, thanks. Though I must say I have not tried any of them (no need, defaults worked fine for me the last years). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:20, 27 March 2017 (UTC)
 

Revision as of 10:20, 11 April 2017

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)