Talk:CPU frequency scaling

From ArchWiki
(Redirected from Talk:Cpufrequtils)
Jump to: navigation, 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?

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)