ondemand as default governor
I just read in drivers/cpufreq/Kconfig:
# Note that it is not currently possible to set the other governors (such as ondemand)
# as the default, since if they fail to initialise, cpufreq will be # left in an undefined state.
Is this a bigger problem to solve?
Is there already someone working/thinking on/about a solution?
Allowing this would be convenient...
Thanks,
Thomas
Quoted 11 lines · Thomas Renninger
I just read in
drivers/cpufreq/Kconfig:# Note that it is not currently possible to set the other governors (such as ondemand)
# as the default, since if they fail to initialise, cpufreq will be # left in an undefined state.Is this a bigger problem to solve?
Is there already someone working/thinking on/about a solution?Allowing this would be convenient...
Yes, it would, then we could delete the other governors, and then delete the concept of multiple governors alltogether.
-Len
Quoted 8 lines · Len Brown
Quoted 7 lines · Thomas Renninger
I just read in
drivers/cpufreq/Kconfig:# Note that it is not currently possible to set the other governors (such as ondemand)
# as the default, since if they fail to initialise, cpufreq will be # left in an undefined state.
Quoted 7 lines
Quoted 4 lines
Is this a bigger problem to solve?
Is there already someone working/thinking on/about a solution?Allowing this would be convenient...
Yes, it would, then we could delete the other governors, and then delete the concept of multiple governors alltogether.
It's not feasible unless you have a way of making various older CPUs transition faster. Ondemand on longhaul,powernow-k6,longrun, elanfreq, as well as lots of non-x86 implementations is just not a feasible option.
However.. conservative might be. I'd still like to see conservative folded into ondemand sometime, and just be a module param.
Dave
Signature · 1 line
http://www.codemonkey.org.uk
Quoted 17 lines · Dave Jones
Quoted 8 lines · Len Brown
Quoted 7 lines · Thomas Renninger
I just read in
drivers/cpufreq/Kconfig:# Note that it is not currently possible to set the other governors (such as ondemand)
# as the default, since if they fail to initialise, cpufreq will be # left in an undefined state.Quoted 7 lines
Quoted 4 lines
Is this a bigger problem to solve?
Is there already someone working/thinking on/about a solution?Allowing this would be convenient...
Yes, it would, then we could delete the other governors, and then delete the concept of multiple governors alltogether.
Quoted 7 lines
It's not feasible unless you have a way of making various older CPUs transition faster. Ondemand on longhaul,powernow-k6,longrun, elanfreq, as well as lots of non-x86 implementations is just not a feasible option.
However.. conservative might be. I'd still like to see conservative folded into ondemand sometime, and just be a module param.
I like the several governors concept in general, cpuidle also goes this way now? I'd just like to see cpufreq working by simply loading the drivers.
I thought I could just set ondemand as default and things work on most machines, instead of fixing the setup in rescue, installation, whatever environment.
Especially ThinkPads tend to run hot quite quickly...
Thomas
Hi,
Dave Jones <[email protected]> [20070307 02:02:08 -0500]:
Quoted 15 lines · Len Brown
Quoted 13 lines · Thomas Renninger
Quoted 11 lines
I just read in
drivers/cpufreq/Kconfig:# Note that it is not currently possible to set the other governors (such as ondemand)
# as the default, since if they fail to initialise, cpufreq will be # left in an undefined state.Is this a bigger problem to solve?
Is there already someone working/thinking on/about a solution?Allowing this would be convenient...
Quoted 8 lines
Quoted 2 lines
Yes, it would, then we could delete the other governors, and then delete the concept of multiple governors alltogether.
It's not feasible unless you have a way of making various older CPUs transition faster. Ondemand on longhaul,powernow-k6,longrun, elanfreq, as well as lots of non-x86 implementations is just not a feasible option.
As a compromise I guess someone could make a patch that 'forces' ondemand/conservative by default with a few '#ifdef's. Slap a huge "we will simply laugh at you if you complain this does not work" in the Kconfig help section and everyones happy. It should be a rather un-intrusive patch.
Quoted 3 lines
However.. conservative might be. I'd still like to see conservative folded into ondemand sometime, and just be a module param.
This was originally touted as this but Dominik[1] suggested it would be a far better use of the modular governor system if I forked a different governor instead. Also if you look at the current userland tools out there that tweak the /sys/.../cpufreq/ settings you will find they really are all kitted out to flip between completely different governors on system events rather than sit on a particular one and tweak a few parameters when someone yanks the power lead[2].
I would admit it looks and feel the kind of thing that should be run into a single governor[3] but this would really muck around the userland tools as they would have to be re-written to actually know the workings of each particular governor rather than just being told "use this one when on AC and this one when not". It would clean up the kernel land forking, but the cost to the userland side would be horrible.
Cheers
Alex
[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=109808470906084&w=2
[2] this seems to be the main use for my governor, laptop users use ondemend when on AC power and use something like the Debian laptop-mode-tools package to flip to conservative when they unplug; I know I do
[3] as the conservative maintainer I just try to minimise the size of the diff file produced between ondemand and conservative :)
Quoted 10 lines
Dave
Signature · 6 lines
http://www.codemonkey.org.uk _______________________________________________ Cpufreq mailing list [email protected] http://lists.linux.org.uk/mailman/listinfo/cpufreq
Signature · 10 lines
____________________________________
/ May you live in interesting times. \
| |
\ -- Chinese proverb /
------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||_______________________________________________
Cpufreq mailing list
[email protected]
http://lists.linux.org.uk/mailman/listinfo/cpufreq
Quoted 34 lines · Alexander Clouter
Hi,
Dave Jones <[email protected]> [20070307 02:02:08 -0500]:
Quoted 15 lines · Len Brown
Quoted 13 lines · Thomas Renninger
Quoted 11 lines
I just read in
drivers/cpufreq/Kconfig:# Note that it is not currently possible to set the other governors (such as ondemand)
# as the default, since if they fail to initialise, cpufreq will be # left in an undefined state.Is this a bigger problem to solve?
Is there already someone working/thinking on/about a solution?Allowing this would be convenient...
Quoted 8 lines
Quoted 2 lines
Yes, it would, then we could delete the other governors, and then delete the concept of multiple governors alltogether.
It's not feasible unless you have a way of making various older CPUs transition faster. Ondemand on longhaul,powernow-k6,longrun, elanfreq, as well as lots of non-x86 implementations is just not a feasible option.
As a compromise I guess someone could make a patch that 'forces' ondemand/conservative by default with a few '#ifdef's. Slap a huge "we will simply laugh at you if you complain this does not work" in the
Kconfighelp section and everyones happy. It should be a rather un-intrusive patch.Quoted 3 lines
However.. conservative might be. I'd still like to see conservative folded into ondemand sometime, and just be a module param.
Quoted 7 lines
This was originally touted as this but Dominik[1] suggested it would be a far better use of the modular governor system if I forked a different governor instead. Also if you look at the current userland tools out there that tweak the
/sys/.../cpufreq/settings you will find they really are all kitted out to flip between completely different governors on system events rather than sit on a particular one and tweak a few parameters when someone yanks the power lead[2].
It isn't self-evident that AC/DC events merit swapping out the P-state policy.
Quoted 6 lines
I would admit it looks and feel the kind of thing that should be run into a single governor[3] but this would really muck around the userland tools as they would have to be re-written to actually know the workings of each particular governor rather than just being told "use this one when on AC and this one when not". It would clean up the kernel land forking, but the cost to the userland side would be horrible.
The user-land tools are going to change over time anyway as Linux actually gets a clue about run-time power management policies.
Quoted 1 line
[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=109808470906084&w=2
Overdesigned for what it does.
There, I said it.
I'm not trying to offend, that is just how I see it.
Quoted 3 lines
[2] this seems to be the main use for my governor, laptop users use ondemend when on AC power and use something like the Debian laptop-mode-tools package to flip to conservative when they unplug; I know I do
Why?
Have you measured better power and performance using conservative vs ondemand. Tools exist to give us hard data on this:
http://sourceforge.net/projects/bltk
Quoted 2 lines
[3] as the conservative maintainer I just try to minimise the size of the diff file produced between ondemand and conservative :)
good, that should make consolidating it easier.
thanks,
-Len
Quoted 42 lines · Alexander Clouter
Hi,
Dave Jones <[email protected]> [20070307 02:02:08 -0500]:
Quoted 15 lines · Len Brown
Quoted 13 lines · Thomas Renninger
Quoted 11 lines
I just read in
drivers/cpufreq/Kconfig:# Note that it is not currently possible to set the other governors (such as ondemand)
# as the default, since if they fail to initialise, cpufreq will be # left in an undefined state.Is this a bigger problem to solve?
Is there already someone working/thinking on/about a solution?Allowing this would be convenient...
Quoted 8 lines
Quoted 2 lines
Yes, it would, then we could delete the other governors, and then delete the concept of multiple governors alltogether.
It's not feasible unless you have a way of making various older CPUs transition faster. Ondemand on longhaul,powernow-k6,longrun, elanfreq, as well as lots of non-x86 implementations is just not a feasible option.
As a compromise I guess someone could make a patch that 'forces' ondemand/conservative by default with a few '#ifdef's. Slap a huge "we will simply laugh at you if you complain this does not work" in the
Kconfighelp section and everyones happy. It should be a rather un-intrusive patch.Quoted 3 lines
However.. conservative might be. I'd still like to see conservative folded into ondemand sometime, and just be a module param.
This was originally touted as this but Dominik[1] suggested it would be a far better use of the modular governor system if I forked a different governor instead. Also if you look at the current userland tools out there that tweak the
/sys/.../cpufreq/settings you will find they really are all kitted out to flip between completely different governors on system events rather than sit on a particular one and tweak a few parameters when someone yanks the power lead[2].
Quoted 6 lines
I would admit it looks and feel the kind of thing that should be run into a single governor[3] but this would really muck around the userland tools as they would have to be re-written to actually know the workings of each particular governor rather than just being told "use this one when on AC and this one when not". It would clean up the kernel land forking, but the cost to the userland side would be horrible.
Well, but there are also userland tools which are heading into another direction. The quite new CPUFreq addon which comes along with HAL tries to go away from the modular governor system. It doesn't limit anyone to set whichever governor is available, but ideally it encourages applications to set one dynamic scaling governor such as ondemand. After setting the governor, you have a scale between 1 and 100 which in turn just tweaks the different settings of this one governor set. And in the long run, distributions will have to use this mechanism if they like to use the most common power management desktop applets out there (gnome-power-manager, kpowersave, etc.).
[...]
Regards,
Holger
Quoted 29 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dave Jones
Sent: Tuesday, March 06, 2007 11:02 PM
To: Len Brown
Cc: [email protected]
Subject: Re: ondemand as default governorQuoted 4 lines · Len Brown
Quoted 3 lines · Thomas Renninger
I just read in
drivers/cpufreq/Kconfig:# Note that it is not currently possible to set the other
governors
Quoted 2 lines
Quoted 2 lines
(such as ondemand)
# as the default, since if they fail to initialise,cpufreq will be
Quoted 9 lines
Quoted 6 lines
# left in an undefined state.Is this a bigger problem to solve?
Is there already someone working/thinking on/about a solution?Allowing this would be convenient...
Yes, it would, then we could delete the other governors, and then delete the concept of multiple governors alltogether.
Quoted 9 lines
It's not feasible unless you have a way of making various older CPUs transition faster. Ondemand on longhaul,powernow-k6,longrun,
elanfreq, as well as lots of non-x86 implementations is just not a feasible option.However.. conservative might be. I'd still like to see conservative folded into ondemand sometime, and just be a module param.
One option I was thinking of doing is to add a rating system to all governors and to try init'ing all governors in order of their rating at init time (until one is successful). With that, we can fallback to performance or userspace if ondemand fails to init.
But, I never got around to implementing something like that.....
Thanks,
Venki
Quoted 37 lines · Venkatesh
Quoted 27 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dave Jones
Sent: Tuesday, March 06, 2007 11:02 PM
To: Len Brown
Cc: [email protected]
Subject: Re: ondemand as default governorQuoted 3 lines · Len Brown
Quoted 2 lines · Thomas Renninger
I just read in
drivers/cpufreq/Kconfig:
# Note that it is not currently possible to set the othergovernors
Quoted 2 lines
Quoted 2 lines
(such as ondemand)
# as the default, since if they fail to initialise,cpufreq will be
Quoted 9 lines
Quoted 6 lines
# left in an undefined state.Is this a bigger problem to solve?
Is there already someone working/thinking on/about a solution?Allowing this would be convenient...
Yes, it would, then we could delete the other governors, and then delete the concept of multiple governors alltogether.
Quoted 9 lines
It's not feasible unless you have a way of making various older CPUs transition faster. Ondemand on longhaul,powernow-k6,longrun,
elanfreq, as well as lots of non-x86 implementations is just not a feasible option.However.. conservative might be. I'd still like to see conservative folded into ondemand sometime, and just be a module param.
Quoted 6 lines
One option I was thinking of doing is to add a rating system to all governors and to try init'ing all governors in order of their rating at init time (until one is successful). With that, we can fallback to performance or userspace if ondemand fails to init.
But, I never got around to implementing something like that.....
There are drivers to work correctly with ondemand and the others are known
to not work with it, right?
Using userspace governor as default does not save much as it needs fiddling in /sys/.../cpufreq anyway, ondemand as default would be much more useful.
What about just falling back to performance governor when a non working driver is loaded with DEFAULT_ONDEMAND governor?
A more clean way could be to add a .max_allowed_latency value to the governor struct and fallback to performance if the latency of the driver is too high (in init of cpufreq driver, instead of comparing governor name)?
This is an example without latency checking, modified two drivers, one known working with ondemand (powernow-k8) and one not (speedstep-smi, AFAIK this one has latency problems):
--- arch/i386/kernel/cpu/cpufreq/powernow-k8.c | 1 - arch/i386/kernel/cpu/cpufreq/speedstep-smi.c | 7 ++++++- drivers/cpufreq/Kconfig | 13 +++++++++++++ drivers/cpufreq/cpufreq.c | 2 ++ drivers/cpufreq/cpufreq_ondemand.c | 7 ++++--- include/linux/cpufreq.h | 5 +++++ 6 files changed, 30 insertions(+), 5 deletions(-)
arch/i386/kernel/cpu/cpufreq/powernow-k8.c +0 -1
@@ -1203,7 +1203,6 @@ static int __cpuinit powernowk8_cpu_init/* run on any CPU again */ set_cpus_allowed (current, oldmask); - pol->governor =CPUFREQ_DEFAULT_GOVERNOR ;if (cpu_family ==CPU_HW_PSTATE ) pol->cpus =cpumask_of_cpu (pol->cpu);else
drivers/cpufreq/cpufreq_ondemand.c +4 -3
@@ -573,11 +573,12 @@ static int cpufreq_governor_dbs(struct creturn 0 ; } -static struct cpufreq_governor cpufreq_gov_dbs = { +struct cpufreq_governor cpufreq_gov_ondemand = { .name ="ondemand" , .governor = cpufreq_governor_dbs, .owner =THIS_MODULE , }; +EXPORT_SYMBOL (cpufreq_gov_ondemand);static int __init cpufreq_gov_dbs_init (void ) {
@@ -586,12 +587,12 @@ static int __init cpufreq_gov_dbs_init(vprintk (KERN_ERR "Creation of kondemand failed\n" );return -EFAULT ; } -return cpufreq_register_governor (&cpufreq_gov_dbs); +return cpufreq_register_governor (&cpufreq_gov_ondemand); } static void __exit cpufreq_gov_dbs_exit(void) { -cpufreq_unregister_governor (&cpufreq_gov_dbs); +cpufreq_unregister_governor (&cpufreq_gov_ondemand);destroy_workqueue (kondemand_wq); }
include/linux/cpufreq.h +5 -0
@@ -286,6 +286,11 @@ extern struct cpufreq_governor cpufreq_g#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE )extern struct cpufreq_governor cpufreq_gov_userspace;#define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_userspace +#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND ) +extern struct cpufreq_governor cpufreq_gov_ondemand; +extern struct cpufreq_governor cpufreq_gov_performance; +#define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_ondemand; +#define CPUFREQ_PERFORMANCE_GOVERNOR &cpufreq_gov_performance;#endif
drivers/cpufreq/Kconfig +13 -0
@@ -75,6 +75,19 @@ config CPU_FREQ_DEFAULT_GOV_USERSPACE program shall be able to set the CPU dynamically without having to enable the userspace governor manually. +config CPU_FREQ_DEFAULT_GOV_ONDEMAND + bool "ondemand" + select CPU_FREQ_GOV_ONDEMAND + select CPU_FREQ_GOV_PERFORMANCE + help + Use the CPUFreq governor 'ondemand' as default. This allows + you to get a full dynamic frequency capable system by simply + loading your cpufreq driver. + Be aware that not all cpufreq drivers support the ondemand + governor. If unsure have a look at the help section of the + driver. Fallback governor will then be the performance + governor. + endchoice config CPU_FREQ_GOV_PERFORMANCE
arch/i386/kernel/cpu/cpufreq/speedstep-smi.c +6 -1
@@ -290,7 +290,12 @@ static int speedstep_cpu_init(struct cpu (speed / 1000));/* cpuinfo and default policy values */ - policy->governor =CPUFREQ_DEFAULT_GOVERNOR ; +#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND +/* this driver does not support ondemand as governor +due to too high latency values */ + policy->governor =CPUFREQ_PERFORMANCE_GOVERNOR ; +#endif + policy->cpuinfo.transition_latency =CPUFREQ_ETERNAL ; policy->cur = speed;
drivers/cpufreq/cpufreq.c +2 -0
@@ -762,6 +762,8 @@ static int cpufreq_add_dev (struct sys_d/* call driver. From then on the cpufreq must be able * to accept all calls to ->verify and ->setpolicy for this CPU */ + policy->governor =CPUFREQ_DEFAULT_GOVERNOR ; + ret = cpufreq_driver->init (policy);if (ret) {dprintk ("initialization failed\n" );