Difference between revisions of "Talk:CPU frequency scaling"

From ArchWiki
Jump to: navigation, search
(Move to cpufrequtils)
(Will systemd#Temporary files work to make changes permanent?: add to re, close)
 
(29 intermediate revisions by 7 users not shown)
Line 1: Line 1:
Hi, I would like to have some feedback regarding my addition to this page: [[Cpufrequtils#Cpufrequtils and Laptop Mode Tools]].
+
== CPU frequency driver ==
  
Thank you.
+
"Note: As of kernel 3.4; the native cpu module is loaded automatically"
  
rent0n
+
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)
  
== Laptop mode ==
+
this still workinkg?
  
I think it's good. What we need, at least in my opinion, is to make this page a bit more pedagogic. As for now I see users becoming confused as to what module(s) they need and how to set it up. A user in the forum misunderstood this wiki page and struggled because he/she did add practically all possible modules to rc.conf.
+
greetings
  
== p4-clockmod + ondemand governor issues ==
+
-- [[User:Sl1pkn07|Sl1pkn07]] ([[User talk:Sl1pkn07|talk]]) 16:00, 21 January 2013 (UTC)
  
Hello,
+
: Worked for me now. More than 4 years after the [[User:Sl1pkn07|Sl1pkn07]]'s post. Most probably with other setup then his. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 22:27, 17 March 2017 (UTC)
I'd like to point out that there's an issue with the p4-clockmod driver combined with the ondemand governor,
 
as seen here:
 
  
https://bbs.archlinux.org/viewtopic.php?id=78408
+
== Intel Sandybridge and higher CPU governors ==
  
In short, the advice given in this wiki article isn't actually working(anymore) and for a newcomer(like me) there isn't really
+
[https://unix.stackexchange.com/questions/121410/setting-cpu-governor-to-on-demand-or-conservative Long story]
a working substitute(as in re-compiling the kernel and modules).
 
  
== acpid ==
+
===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)
  
I found that acpi events were not processed until I installed acpid and added that to the daemon list (I removed laptop-mode).
+
== <s>Will systemd#Temporary files work to make changes permanent?</s> ==
  
== Move to [[cpufrequtils]] ==
+
[[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)
  
I'm not sure why this page that specifically covers the cpufrequtils package was moved from cpufrequtils to this more generic title. The article title should match the package/utility described within, in my opinion. -- [[User:Pointone|pointone]] 18:41, 25 January 2011 (EST)
+
: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)
  
:The page contains incorrect information right now - it confuses the kernel's cpufreq with the userspace cpufrequtils package. All of the stuff on the page about drivers/modules, governors, /sys, etc. is independent of cpufreq'''utils'''. cpufrequtils provides a daemon script to set the governors and 3 userspace utilities, which offer similar functionality to the /sys filesystem and powertop. The two methods on the page for using laptop-mode-tools and acpid to set the governor are completely independent of cpufrequtils. I moved the page here after someone resurrected the old version that got merged into this article, because they were right that cpufrequtils != cpufreq, but there was also no reason to have 2 pages describing the same stuff. [[User:Thestinger|thestinger]] 19:29, 25 January 2011 (EST)
+
::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)
  
::I resurrected this page because of the reason mentioned by Thestinger. You only need the kernel modules (and to set a governor other than performance) for frequency scaling to work, any additional tools aren't needed (and thus don't "comply" with [[The Arch Way]]). Personally I'd suggest to either collect all tools/daemons on this page in a separate section and have either the pages for all individual tools/daemons redirect to this page or remove all those pages. The other options would be to either have one page with all tools/daemons on it or separate pages for all individual tools/daemons and link them from this page in a separate section. [[User:Aaahaaap|Aaahaaap]] 14:16, 27 January 2011 (EST)
+
::: 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}}.}}
  
:::A clean article explaining the various available modules / governors would get my vote, tools to do additional configuration should have a private section in this same article.
+
::: {{unsigned| 07:10, 19 March 2017‎|Regid}}
::: I would suggest something like this:
 
::: 1 - Configuration (explain the requirements, note that 3.4+ kernels will auto-load and provide users with a working setup)
 
::: 2 - CPU frequency drivers (detail a list of available drivers, match them to chipsets)
 
::: 3 - Governors (detail a list of available governors, explain their intended use)
 
::: 4 - Userspace tools (cpufreq, pm-utils etc etc)
 
::: 5 - Troubleshooting
 
:::
 
::: We might consider extracting the user-space tools configuration to separate wiki-pages per user-space tool and linking to those articles. I doubt these user-space tools have such expansive features that they require such an approach though, I'd leave them included here. Snug together in a private section.
 
:::
 
::: Something like this: https://wiki.archlinux.org/index.php/User:Stefanwilkens ?
 
:::--[[User:Stefanwilkens|stefanwilkens]] ([[User talk:Stefanwilkens|talk]]) 10:45, 15 September 2012 (UTC)
 
  
== Troubleshooting - BIOS frequency limitation ==
+
:::: 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)  
I tried to rewrite this section with my very limited knowledge on this topic so there's not so much confusing details about specific hardware and more general explanation. (That I hope is not completely wrong)
 
  
Can anyone with more ACPI,hardware,etc.-knowledge give an assessment if the warnings must be so strict.
+
:::::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:
In fact I've used my old thinkpad with a completely dead battery and this "solution" for over two years now without any problems, even not under relative demanding ego-shooters ;)
+
{{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)
  
Just didn't want to ruin other peoples hardware.
+
::::::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)
  
It's always nice to get feedback :)
+
:::::::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)
  
btw. any idea why there is the accuracy template for the whole troubleshooting-section without any reason written there? thx
+
::::::::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)
[[User:Nonix|Nonix]] ([[User talk:Nonix|talk]]) 00:01, 17 August 2012 (UTC)
 

Latest revision as of 20:22, 27 March 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)

Will systemd#Temporary files work to make changes permanent?

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 /sys when kernel modules are involved. Did I get it wrong? 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 /etc/modprobe.d rule first. If no-one has a definite answer regarding /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. --Indigo (talk) 11:05, 18 March 2017 (UTC)
If I'm not mistaken the cpufreq modules don't have any options that could be set by modprobe. -- 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 acpi_cpufreq, you could create or edit a /etc/modprobe.d/cpu-sampling-down.conf file as follow:
/etc/modprobe.d/cpu-sampling-down.conf
install acpi_cpufreq \
echo 40 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor \
/sbin/modprobe --ignore-install acpi-cpufreq $CMDLINE_OPTS
Note: If any of the affected modules is loaded from the initramfs, you will need to add the appropriate .conf file to FILES in mkinitcpio.conf or use the modconf hook, so that it will be included in the initramfs. To see the contents of the default initramfs use lsinitcpio /boot/initramfs-linux.img.
—This unsigned comment is by Regid (talk) 07:10, 19 March 2017‎. Please sign your posts with ~~~~!
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 /sys quirks (powersaving etc). I've googled again and first I saw that systemd explicitly mentions /sys without reservations. Then, stackexchange has a lot info, including [1]. Perhaps our systemd note about /sys problems is just outdated? --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:
/etc/modprobe.d/cpu-sampling-down.conf
install acpi_cpufreq /sbin/modprobe --ignore-install acpi_cpufreq $CMDLINE_OPTS; \
echo 40 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
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 Indigo comment above. I do believe modprobe.d is the way to go becuase it looks to me more natural when modules are involved, and less complicated. Regid (talk) 05:19, 20 March 2017 (UTC)
Your command assumes that the /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 /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. -- 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 stackoverflow, which is only half year old, is our final station.
/etc/udev/rules.d/50-cpu-sampling-down.rules
SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+="/bin/sh -c 'echo 40 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor'"
It is probably should be added to the initramfs.
Is it agreed to edit the article accordingly?
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). --Indigo (talk) 20:20, 27 March 2017 (UTC)