...in order to be full replacement to other obsolete cpufreq packages in tree looking at cpufrequtils/files/ for it's conf.d and init.d it should be rather easy to port those. The replacement for the commands used in cpufrequtils could be something like: ebegin "Running cpupower frequency-set ${opts}" ... snip for c in $(cpupower frequency-info | awk '$2 == "CPU" { print $3 }' | cut -c 1); ... snip cpupower frequency-set -c ${c} ${opts}
(In reply to comment #0) Samuli ... > looking at cpufrequtils/files/ for it's conf.d and init.d it should be > rather easy to port those. The replacement for the commands used in > cpufrequtils could be something like: > for c in $(cpupower frequency-info | awk '$2 == "CPU" { print $3 }' | cut -c > 1); That will also output the 'f' of 'frequency' as the line 'current' also has 'CPU' in the third field. Also, without a '-c cpulist' it defaults to '0' and so we'd only get '0' (and the stray 'f'). It would need to be more explicit: cpupower -c all info |awk '{gsub(/:/,""); if ($2 == "CPU") print $3}' or ... cpupower -c all info |awk '/^analyzing.*/{gsub(/:/,""); print $3}' ... but really this isn't necessary, because we can use 'all' in the following and so don't need to collect the number of CPU's. > cpupower frequency-set -c ${c} ${opts} cpupower -c all frequency-set ${opts} >/dev/null 2>&1 The attatched rc works setting governer and EXTRA_OPTS (though I'm not sure what the policy is on rediecting stdout and stderr to /dev/null ... thats possible fround apon). Still, there are a number of other features/options that might be worth adding, such as -u (maximum clock frequency) and -d (minimum clock frequency)
Created attachment 346342 [details] cpupower rcscript
Comment on attachment 346342 [details] cpupower rcscript Thanks. I've committed initial conf.d and init.d files (this attachement but only minorly cleaned up) to tree together with cpupower from final 3.8 release. Trying to get more people onboard with this...
(In reply to comment #3) Samuli ... > I've committed initial conf.d and init.d files (this attachement but only > minorly cleaned up) to tree together with cpupower from final 3.8 release. the conf.d from cpufrequtils had default governers for start/stop, and also had EXTRA_OPTS defined, the latter was commented but it does provide some idea of what values might be applied. As the rcscript also supports this it might be an idea to add something similar, I have: SYSFS_EXTRA="ondemand/ignore_nice_load=1 ondemand/up_threshold=15 ondemand/sampling_down_factor=10" It may also be good to add some description: # up_threshold: threshold for stepping up frequency, where the value represents # the percentage of cpu load. # down_threshold: threshold for stepping down frequency, where the value # represents the percentage of cpu load. # sampling_down_factor: determines how frequently the governor polls the cpu, a # value greater than 1 improves performance by reducing the polling when the # load it high. This tunable has no effect on behavior at lower CPU frequencies # ignore_nice_load: when set to '1', the processes that are run with a 'nice' # value will not count in the usage calculation. The above up_threshold=15 will allow for idling at the lower frequencies but switching to a higher frequency should happen quickly, and so performance should be similar to running at a high frequency. I think the cpufrequtils conf.d had this set at 75, but I'm inclined to think a lower value would be a better default (your call). Anyhow, attatched is a possible replacement. > Trying to get more people onboard with this... I'll make somekind of post in the forum detailing the many ills of cpufreqd. best ... khay
Created attachment 346372 [details] /etc/conf.d/cpupower
(In reply to comment #4) > the conf.d from cpufrequtils had default governers for start/stop, and also > had EXTRA_OPTS defined, the latter was commented but it does provide some > idea of what values might be applied. As the rcscript also supports this it > might be an idea to add something similar, I have: > > SYSFS_EXTRA="ondemand/ignore_nice_load=1 ondemand/up_threshold=15 > ondemand/sampling_down_factor=10" I wasn't sure if these values could be passed like that anymore... are you sure about the syntax?
(In reply to comment #6) > (In reply to comment #4) > > SYSFS_EXTRA="ondemand/ignore_nice_load=1 ondemand/up_threshold=15 > > ondemand/sampling_down_factor=10" > > I wasn't sure if these values could be passed like that anymore... are you > sure about the syntax? Yes, seems to work just as it did with cpufrequtils: # cat /sys/devices/system/cpu/cpufreq/ondemand/up_threshold 15 # cat /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor 10 # cat /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load 1 best ... khay
Created attachment 346378 [details] /etc/conf.d/cpupower corrected some spelling and reorganised for better comprehension
(In reply to comment #7) > Yes, seems to work just as it did with cpufrequtils: OK, in Portage as =sys-power/cpupower-3.8-r1 Thanks again Will still keep this open for a while so people find it easier and can post improvements here
(In reply to comment #9) Samuli ... > Will still keep this open for a while so people find it easier and can post > improvements here ya, probably a good idea. I'm attatching a patch for the rcscript that adds an -n test for '$opts', this way if the value is empty then the set is skipped. The reason for this is on a restart it doesn't make sense to set '-g performance' and then '-g ondemand' right after, with the test STOP_OPTS can be undefined and so the governer remain on START_OPT. If using ondemand then there is little reason to switch to performance (or some other governer) on shutdown, or when restarting the service. I'm also attaching an updated conf.d with further information as to what can be set via *_OPTS, and removing the governer from STOP_OPTS. I've also raised the value for up_threshold in SYSFS_EXTRA (still commented), but I'm really not sure *what* value this might best be set to (perhaps the "75" as defined by cpufrequtils is a better default ... 95% being the value set by ondemand if nothing it provided). Sorry to have all these minor changes come in such quick succession hopefully you see them an improvement rather than an annoyance. best ... khay
Created attachment 346468 [details, diff] patch for init.d
Created attachment 346470 [details] conf.d for cpupower
When I emerge sys-power/cpupower-3.8_rc4, it's not pulling in the conf.d or init.d files.
(In reply to comment #13) > When I emerge sys-power/cpupower-3.8_rc4, it's not pulling in the conf.d or > init.d files. 3.8_rc4 is not in portage anymore, time to emerge --sync
sys-power/cpupower-3.8-r1 : I'm getting: /etc/init.d/cpupower : line 22 : ${o} : ambiguous redirect :on boot, not having any problems setting frequency.
Comment on attachment 346468 [details, diff] patch for init.d In portage.
Comment on attachment 346470 [details] conf.d for cpupower In Portage.
I've been using the new Intel PState driver (CONFIG_X86_INTEL_PSTATE) with great success for a while now (it can be run in performance mode without the impact of the ondemand governor, even with tuning) and the init script fails for me: root>/etc/init.d/cpupower start * Running cpupower -c all frequency-set --governor ondemand ... [ !! ] * Setting extra options: /etc/init.d/cpupower: line 18: cd: /sys/devices/system/cpu/cpufreq: No such file or directory [ !! ] * ERROR: cpupower failed to start root>ll /sys/devices/system/cpu total 0 drwxr-xr-x 8 root root 0 Sep 27 13:05 cpu0/ drwxr-xr-x 8 root root 0 Sep 27 13:05 cpu1/ drwxr-xr-x 8 root root 0 Sep 27 13:05 cpu2/ drwxr-xr-x 8 root root 0 Sep 27 13:05 cpu3/ drwxr-xr-x 2 root root 0 Sep 27 15:11 cpuidle/ drwxr-xr-x 2 root root 0 Sep 27 15:17 intel_pstate/ -r--r--r-- 1 root root 4.0K Sep 27 15:17 kernel_max -r--r--r-- 1 root root 4.0K Sep 27 15:17 modalias -r--r--r-- 1 root root 4.0K Sep 27 15:17 offline -r--r--r-- 1 root root 4.0K Sep 27 13:03 online -r--r--r-- 1 root root 4.0K Sep 27 15:17 possible drwxr-xr-x 2 root root 0 Sep 27 15:17 power/ -r--r--r-- 1 root root 4.0K Sep 27 15:17 present --w------- 1 root root 4.0K Sep 27 15:17 probe --w------- 1 root root 4.0K Sep 27 15:17 release -rw-r--r-- 1 root root 4.0K Sep 27 15:17 uevent root> What would be the best way to check whether the SYSFS_EXTRA options can be applied? Checking for the cpufreq sysfs entry?
Created attachment 359620 [details, diff] Patch to init script to ignore empty START/STOP_OPTS and skip nonexisting sysfs entry This patch will ignore empty START/STOP_OPTS (by default STOP_OPTS is empty) and skip any attempt to set SYSFS_EXTRA when the Intel pstate driver is used. These changes work for me, though the changes may not bethe best Shell coding style.
Created attachment 359622 [details, diff] Patch to init script to ignore empty START/STOP_OPTS and skip nonexisting sysfs entry Proper patch, previous was bungled and didn't apply.
Created attachment 359624 [details, diff] Patch to init script to skip nonexisting sysfs entry My diff-fu is weak today: patch to only fix the sysfs issue.
Comment on attachment 359624 [details, diff] Patch to init script to skip nonexisting sysfs entry In portage.
Created attachment 361548 [details, diff] init.d-r3.diff When I run cpupower init script I get the following error message: # /etc/init.d/cpupower restart * Caching service dependencies ... [ ok ] * Running cpupower -c all frequency-set --governor performance ... [ ok ] * Running cpupower -c all frequency-set --governor ondemand ... [ ok ] * Setting extra options: /lib64/rc/sh/runscript.sh: 25: /lib64/rc/sh/runscript.sh: cannot create : Directory nonexistent [ ok ] This is due to the SYSFS_EXTRA variable in conf.d/cpupower being unset / commented out. The attached patch fixes this problem.
Comment on attachment 361548 [details, diff] init.d-r3.diff In portage -- starting with cpupower-3.12
What is blocking this from being closed (well, I just got another report for the old cpufreqd in "maintainer-needed" alias and wondered if pointing people to cpupower would be ok at this stage :/) Thanks!
(In reply to Pacho Ramos from comment #25) > What is blocking this from being closed (well, I just got another report for > the old cpufreqd in "maintainer-needed" alias and wondered if pointing > people to cpupower would be ok at this stage :/) > > Thanks! we kept this bug open because of the active work being done on the init and conf files so the bug could easily be found but I guess we can close it now. the cpupower package is ready far as I'm concerned, can be stabilized too at will
