[RFC] [PATCH] cpufreq: allow full selection of default governors

[RFC] [PATCH] cpufreq: allow full selection of default governors

[William Heimbigner]

The following patches should allow selection of conservative, powersave, and 
ondemand in the kernel configuration.

William Heimbigner
icxcnika@mar.tar.cc

diff -uprN -X linux-2.6.21-rc7-git6/Documentation/dontdiff linux-2.6.21-rc7-git6/drivers/cpufreq/Kconfig linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/Kconfig
--- linux-2.6.21-rc7-git6/drivers/cpufreq/Kconfig	2007-04-25 13:03:41.000000000 -0500
+++ linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/Kconfig	2007-04-25 13:08:13.000000000 -0500
@@ -75,6 +75,24 @@ 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_POWERSAVE
+	bool "powersave"
+	select CPU_FREQ_GOV_POWERSAVE
+	help
+	  Use the CPUFreq governor 'powersave' as default.
+
+config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
+	bool "conservative"
+	select CPU_FREQ_GOV_CONSERVATIVE
+	help
+	  Use the CPUFreq governor 'conservative' as the default.
+
+config CPU_FREQ_DEFAULT_GOV_ONDEMAND
+	bool "ondemand"
+	select CPU_FREQ_GOV_ONDEMAND
+	help
+	  Use the CPUFreq governor 'ondemand' as the default.
+
  endchoice

  config CPU_FREQ_GOV_PERFORMANCE
diff -uprN -X linux-2.6.21-rc7-git6/Documentation/dontdiff linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_conservative.c linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_conservative.c
--- linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_conservative.c	2007-04-25 13:03:41.000000000 -0500
+++ linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_conservative.c	2007-04-25 09:54:58.000000000 -0500
@@ -551,7 +551,7 @@ static int cpufreq_governor_dbs(struct c
  	return 0;
  }

-static struct cpufreq_governor cpufreq_gov_dbs = {
+struct cpufreq_governor cpufreq_gov_conservative = {
  	.name		= "conservative",
  	.governor	= cpufreq_governor_dbs,
  	.owner		= THIS_MODULE,
@@ -559,7 +559,7 @@ static struct cpufreq_governor cpufreq_g

  static int __init cpufreq_gov_dbs_init(void)
  {
-	return cpufreq_register_governor(&cpufreq_gov_dbs);
+	return cpufreq_register_governor(&cpufreq_gov_conservative);
  }

  static void __exit cpufreq_gov_dbs_exit(void)
@@ -567,7 +567,7 @@ static void __exit cpufreq_gov_dbs_exit(
  	/* Make sure that the scheduled work is indeed not running */
  	flush_scheduled_work();

-	cpufreq_unregister_governor(&cpufreq_gov_dbs);
+	cpufreq_unregister_governor(&cpufreq_gov_conservative);
  }


diff -uprN -X linux-2.6.21-rc7-git6/Documentation/dontdiff linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_ondemand.c linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_ondemand.c
--- linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_ondemand.c	2007-04-25 13:03:41.000000000 -0500
+++ linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_ondemand.c	2007-04-25 13:17:00.000000000 -0500
@@ -573,7 +573,7 @@ static int cpufreq_governor_dbs(struct c
  	return 0;
  }

-static struct cpufreq_governor cpufreq_gov_dbs = {
+struct cpufreq_governor cpufreq_gov_ondemand = {
  	.name = "ondemand",
  	.governor = cpufreq_governor_dbs,
  	.owner = THIS_MODULE,
@@ -586,12 +586,12 @@ static int __init cpufreq_gov_dbs_init(v
  		printk(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);
  }

diff -uprN -X linux-2.6.21-rc7-git6/Documentation/dontdiff linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_powersave.c linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_powersave.c
--- linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_powersave.c	2007-02-04 12:44:54.000000000 -0600
+++ linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_powersave.c	2007-04-25 08:51:03.000000000 -0500
@@ -35,7 +35,7 @@ static int cpufreq_governor_powersave(st
  	return 0;
  }

-static struct cpufreq_governor cpufreq_gov_powersave = {
+struct cpufreq_governor cpufreq_gov_powersave = {
  	.name		= "powersave",
  	.governor	= cpufreq_governor_powersave,
  	.owner		= THIS_MODULE,

diff -uprN -X linux-2.6.21-rc7-git6/Documentation/dontdiff linux-2.6.21-rc7-git6/include/linux/cpufreq.h linux-2.6.21-rc7-git6-hwill/include/linux/cpufreq.h
--- linux-2.6.21-rc7-git6/include/linux/cpufreq.h	2007-04-25 13:04:00.000000000 -0500
+++ linux-2.6.21-rc7-git6-hwill/include/linux/cpufreq.h	2007-04-25 13:10:26.000000000 -0500
@@ -286,6 +286,15 @@ 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_POWERSAVE)
+extern struct cpufreq_governor cpufreq_gov_powersave;
+#define CPUFREQ_DEFAULT_GOVERNOR	&cpufreq_gov_powersave
+#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE)
+extern struct cpufreq_governor cpufreq_gov_conservative;
+#define CPUFREQ_DEFAULT_GOVERNOR	&cpufreq_gov_conservative
+#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND)
+extern struct cpufreq_governor cpufreq_gov_ondemand;
+#define CPUFREQ_DEFAULT_GOVERNOR	&cpufreq_gov_ondemand
  #endif

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[Dave Jones]

On Tue, Apr 24, 2007 at 09:03:23PM +0000, William Heimbigner wrote:
 > The following patches should allow selection of conservative, powersave, and 
 > ondemand in the kernel configuration.

This has been rejected several times already.
Ondemand and conservative isn't a viable governor for all cpufreq implementations
(ie, ones with high switching latencies).  Also, see the comment in the Kconfig
a few lines above where you are adding this.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[Robert P. J. Day]

On Tue, 24 Apr 2007, William Heimbigner wrote:

> The following patches should allow selection of conservative, powersave, and
> ondemand in the kernel configuration.
>
> William Heimbigner
> icxcnika@mar.tar.cc
>
> diff -uprN -X linux-2.6.21-rc7-git6/Documentation/dontdiff
> linux-2.6.21-rc7-git6/drivers/cpufreq/Kconfig
> linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/Kconfig
> --- linux-2.6.21-rc7-git6/drivers/cpufreq/Kconfig	2007-04-25
> 13:03:41.000000000 -0500
> +++ linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/Kconfig	2007-04-25
> 13:08:13.000000000 -0500
> @@ -75,6 +75,24 @@ 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_POWERSAVE
> +	bool "powersave"
> +	select CPU_FREQ_GOV_POWERSAVE
> +	help
> +	  Use the CPUFreq governor 'powersave' as default.
                                                ^^^ the (for consistency)
> +
> +config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
> +	bool "conservative"
> +	select CPU_FREQ_GOV_CONSERVATIVE
> +	help
> +	  Use the CPUFreq governor 'conservative' as the default.
> +
> +config CPU_FREQ_DEFAULT_GOV_ONDEMAND
> +	bool "ondemand"
> +	select CPU_FREQ_GOV_ONDEMAND
> +	help
> +	  Use the CPUFreq governor 'ondemand' as the default.
> +
>  endchoice

rday

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[Chuck Ebbert]

Dave Jones wrote:
> On Tue, Apr 24, 2007 at 09:03:23PM +0000, William Heimbigner wrote:
>  > The following patches should allow selection of conservative, powersave, and 
>  > ondemand in the kernel configuration.
> 
> This has been rejected several times already.
> Ondemand and conservative isn't a viable governor for all cpufreq implementations
> (ie, ones with high switching latencies).  Also, see the comment in the Kconfig
> a few lines above where you are adding this.

It would be nice to have powersave available as the default.

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[Nish Aravamudan]

On 4/24/07, Dave Jones <davej@redhat.com> wrote:
> On Tue, Apr 24, 2007 at 09:03:23PM +0000, William Heimbigner wrote:
>  > The following patches should allow selection of conservative, powersave, and
>  > ondemand in the kernel configuration.
>
> This has been rejected several times already.
> Ondemand and conservative isn't a viable governor for all cpufreq
> implementations (ie, ones with high switching latencies).

This piques my curiosity -- some governors don't work with some
cpufreq implementations. Are those implementations in the kernel or in
userspace? If in the kernel, then perhaps there should be some
dependency expressed there in Kconfig between cpufreq implementation
and the available governors (not just whether the governor can be the
default or not). If that is already expressed, then the available
*default*s should also have their dependency so expressed.

I guess I don't see the point of *not* allowing users to select a
different governor as default at compile-time, if they can change it
at run-time?

The distros would simply not change the DEFAULT selection, but users
that build their own kernels could change it as they wanted.

I guess the issue is, if by allowing a different DEFAULT selection
(albeit one that wouldn't change for existing .configs, I assume), are
we going to break existing setups. It doesn't seem like we would,
*unless* the user goes and changes the default. And they went and
changed it to a default that doesn't work, but that they could easily
have checked doesn't work with their cpufreq implementation by
changing it at run-time in their current kernel. And they are root...

> Also, see the
> comment in the Kconfig a few lines above where you are adding this.

Are these governors unfixable? If

"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 true, presumably "userspace" and "performance" are so written so as
to not leave cpufreq in an undefined state? Could the same be done for
ondemand and powersave?

Just looking for more info -- feel free to just point me at the archives.

Thanks,
Nish

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[William Heimbigner]

On Tue, 24 Apr 2007, Dave Jones wrote:
> On Tue, Apr 24, 2007 at 09:03:23PM +0000, William Heimbigner wrote:
> > The following patches should allow selection of conservative, powersave, and
> > ondemand in the kernel configuration.
>
> This has been rejected several times already.
> Ondemand and conservative isn't a viable governor for all cpufreq implementations
> (ie, ones with high switching latencies).  Also, see the comment in the Kconfig
> a few lines above where you are adding this.
>
> 	Dave

It may be wise to disable the selection of ondemand, however, conservative was 
designed to fix the very problem created by ondemand (the need for high 
switching latencies), and this also says nothing about powersave.

Additionally, it seems odd that the kernel would be left in an undefined state 
if a governor failed to initalize - rather, shouldn't the governor fail in such 
a way as to not cause errors?

William Heimbigner
icxcnika@mar.tar.cc

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[Dave Jones]

On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote:
 > On 4/24/07, Dave Jones <davej@redhat.com> wrote:
 > > On Tue, Apr 24, 2007 at 09:03:23PM +0000, William Heimbigner wrote:
 > >  > The following patches should allow selection of conservative, powersave, and
 > >  > ondemand in the kernel configuration.
 > >
 > > This has been rejected several times already.
 > > Ondemand and conservative isn't a viable governor for all cpufreq
 > > implementations (ie, ones with high switching latencies).
 > 
 > This piques my curiosity -- some governors don't work with some
 > cpufreq implementations. Are those implementations in the kernel or in
 > userspace? If in the kernel, then perhaps there should be some
 > dependency expressed there in Kconfig between cpufreq implementation
 > and the available governors

it can't be solved that easily. powernow-k8 for example is fine to
use with ondemand on newer systems, where the latency is low.
On older models however, it isn't.

 > > Also, see the
 > > comment in the Kconfig a few lines above where you are adding this.
 > 
 > Are these governors unfixable? If

tbh, I've forgotten the original issues that caused the comment
to be placed there. Dominik ?

 > Just looking for more info -- feel free to just point me at the archives.

cpufreq-list archives are at http://lists.linux.org.uk/mailman/listinfo/cpufreq
(though only available to list members)

	Dave

-- 
http://www.codemonkey.org.uk

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[Dominik Brodowski]

On Tue, Apr 24, 2007 at 08:03:27PM -0400, Dave Jones wrote:
> On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote:
>  > On 4/24/07, Dave Jones <davej@redhat.com> wrote:
>  > > On Tue, Apr 24, 2007 at 09:03:23PM +0000, William Heimbigner wrote:
>  > >  > The following patches should allow selection of conservative, powersave, and
>  > >  > ondemand in the kernel configuration.
>  > >
>  > > This has been rejected several times already.
>  > > Ondemand and conservative isn't a viable governor for all cpufreq
>  > > implementations (ie, ones with high switching latencies).
>  > 
>  > This piques my curiosity -- some governors don't work with some
>  > cpufreq implementations. Are those implementations in the kernel or in
>  > userspace? If in the kernel, then perhaps there should be some
>  > dependency expressed there in Kconfig between cpufreq implementation
>  > and the available governors
> 
> it can't be solved that easily. powernow-k8 for example is fine to
> use with ondemand on newer systems, where the latency is low.
> On older models however, it isn't.
> 
>  > > Also, see the
>  > > comment in the Kconfig a few lines above where you are adding this.
>  > 
>  > Are these governors unfixable? If
> 
> tbh, I've forgotten the original issues that caused the comment
> to be placed there. Dominik ?

Not unfixable, but: cpufreq is currently[*] built around the assumption that
at least one governor is correctly initialized or can be brought to work
when a CPU is registered with the cpufreq core.

	Dominik


[*] That is, the last time I looked at it ;)

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[Dave Jones]

On Thu, Apr 26, 2007 at 09:54:10PM -0400, Dominik Brodowski wrote:
 > On Tue, Apr 24, 2007 at 08:03:27PM -0400, Dave Jones wrote:
 > > On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote:
 > >  > On 4/24/07, Dave Jones <davej@redhat.com> wrote:
 > >  > > On Tue, Apr 24, 2007 at 09:03:23PM +0000, William Heimbigner wrote:
 > >  > >  > The following patches should allow selection of conservative, powersave, and
 > >  > >  > ondemand in the kernel configuration.
 > >  > >
 > >  > > This has been rejected several times already.
 > >  > > Ondemand and conservative isn't a viable governor for all cpufreq
 > >  > > implementations (ie, ones with high switching latencies).
 > >  > 
 > >  > This piques my curiosity -- some governors don't work with some
 > >  > cpufreq implementations. Are those implementations in the kernel or in
 > >  > userspace? If in the kernel, then perhaps there should be some
 > >  > dependency expressed there in Kconfig between cpufreq implementation
 > >  > and the available governors
 > > 
 > > it can't be solved that easily. powernow-k8 for example is fine to
 > > use with ondemand on newer systems, where the latency is low.
 > > On older models however, it isn't.
 > > 
 > >  > > Also, see the
 > >  > > comment in the Kconfig a few lines above where you are adding this.
 > >  > 
 > >  > Are these governors unfixable? If
 > > 
 > > tbh, I've forgotten the original issues that caused the comment
 > > to be placed there. Dominik ?
 > 
 > Not unfixable, but: cpufreq is currently[*] built around the assumption that
 > at least one governor is correctly initialized or can be brought to work
 > when a CPU is registered with the cpufreq core.

It would have to take something fairly spectacular though for performance or
powersave to fail registration. Can you remember why we chose not to allow those?

	Dave

-- 
http://www.codemonkey.org.uk

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[Dominik Brodowski]

On Fri, Apr 27, 2007 at 02:09:57AM -0400, Dave Jones wrote:
> On Thu, Apr 26, 2007 at 09:54:10PM -0400, Dominik Brodowski wrote:
>  > On Tue, Apr 24, 2007 at 08:03:27PM -0400, Dave Jones wrote:
>  > > On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote:
>  > >  > On 4/24/07, Dave Jones <davej@redhat.com> wrote:
>  > >  > > On Tue, Apr 24, 2007 at 09:03:23PM +0000, William Heimbigner wrote:
>  > >  > >  > The following patches should allow selection of conservative, powersave, and
>  > >  > >  > ondemand in the kernel configuration.
>  > >  > >
>  > >  > > This has been rejected several times already.
>  > >  > > Ondemand and conservative isn't a viable governor for all cpufreq
>  > >  > > implementations (ie, ones with high switching latencies).
>  > >  > 
>  > >  > This piques my curiosity -- some governors don't work with some
>  > >  > cpufreq implementations. Are those implementations in the kernel or in
>  > >  > userspace? If in the kernel, then perhaps there should be some
>  > >  > dependency expressed there in Kconfig between cpufreq implementation
>  > >  > and the available governors
>  > > 
>  > > it can't be solved that easily. powernow-k8 for example is fine to
>  > > use with ondemand on newer systems, where the latency is low.
>  > > On older models however, it isn't.
>  > > 
>  > >  > > Also, see the
>  > >  > > comment in the Kconfig a few lines above where you are adding this.
>  > >  > 
>  > >  > Are these governors unfixable? If
>  > > 
>  > > tbh, I've forgotten the original issues that caused the comment
>  > > to be placed there. Dominik ?
>  > 
>  > Not unfixable, but: cpufreq is currently[*] built around the assumption that
>  > at least one governor is correctly initialized or can be brought to work
>  > when a CPU is registered with the cpufreq core.
> 
> It would have to take something fairly spectacular though for performance or
> powersave to fail registration. Can you remember why we chose not to allow those?

performance _is_ allowed; powersave would be possible -- but then those who
accidentally enable it on elanfreq might wait 100 times as long for the
system to boot, with gx-suspmod it might even be 255 times as long -- okay,
by default it's just 20 times as long, but still...

	Dominik

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[William Heimbigner]

On Fri, 27 Apr 2007, Dominik Brodowski wrote:
> On Fri, Apr 27, 2007 at 02:09:57AM -0400, Dave Jones wrote:
>> On Thu, Apr 26, 2007 at 09:54:10PM -0400, Dominik Brodowski wrote:
>> > On Tue, Apr 24, 2007 at 08:03:27PM -0400, Dave Jones wrote:
>> >> On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote:
>> >> > On 4/24/07, Dave Jones <davej@redhat.com> wrote:
>> >> >> On Tue, Apr 24, 2007 at 09:03:23PM +0000, William Heimbigner wrote:
>> >> >> > The following patches should allow selection of conservative, powersave, and
>> >> >> > ondemand in the kernel configuration.
>> >> >>
>> >> >> This has been rejected several times already.
>> >> >> Ondemand and conservative isn't a viable governor for all cpufreq
>> >> >> implementations (ie, ones with high switching latencies).
>> >> >
>> >> > This piques my curiosity -- some governors don't work with some
>> >> > cpufreq implementations. Are those implementations in the kernel or in
>> >> > userspace? If in the kernel, then perhaps there should be some
>> >> > dependency expressed there in Kconfig between cpufreq implementation
>> >> > and the available governors
>> >>
>> >> it can't be solved that easily. powernow-k8 for example is fine to
>> >> use with ondemand on newer systems, where the latency is low.
>> >> On older models however, it isn't.
>> >>
>> >> >> Also, see the
>> >> >> comment in the Kconfig a few lines above where you are adding this.
>> >> >
>> >> > Are these governors unfixable? If
>> >>
>> >> tbh, I've forgotten the original issues that caused the comment
>> >> to be placed there. Dominik ?
>> >
>> > Not unfixable, but: cpufreq is currently[*] built around the assumption that
>> > at least one governor is correctly initialized or can be brought to work
>> > when a CPU is registered with the cpufreq core.
>>
>> It would have to take something fairly spectacular though for performance or
>> powersave to fail registration. Can you remember why we chose not to allow those?
>
> performance _is_ allowed; powersave would be possible -- but then those who
> accidentally enable it on elanfreq might wait 100 times as long for the
> system to boot, with gx-suspmod it might even be 255 times as long -- okay,
> by default it's just 20 times as long, but still...
>
> 	Dominik
>

People should be smart enough to realize what "powersave" would imply... or at 
least read the help for it; again, we wouldn't have the "default default 
governor" be powersave, it would be performance, and they could choose 
powersave if they wanted to.

Also, what of the conservative governor? I understand now some of the problems
that could arise with ondemand, but conservative doesn't rely on low-latency
transitions, and seems no riskier than performance or powersave. In fact,
conservative would probably be the most useful default governor available for a
laptop system.

For now, I propose allowing a default governor of powersave; allowing 
conservative while being tagged experimental, and possibly, but not likely, 
allowing ondemand, tagged as experimental.

William Heimbigner
icxcnika@mar.tar.cc

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[Gautham Shenoy]

On 4/27/07, Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> On Fri, Apr 27, 2007 at 02:09:57AM -0400, Dave Jones wrote:
> > On Thu, Apr 26, 2007 at 09:54:10PM -0400, Dominik Brodowski wrote:
> >  > On Tue, Apr 24, 2007 at 08:03:27PM -0400, Dave Jones wrote:
> >  > > On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote:
> >  > >  > On 4/24/07, Dave Jones <davej@redhat.com> wrote:
> >  > >  > > On Tue, Apr 24, 2007 at 09:03:23PM +0000, William Heimbigner wrote:
> >  > >  > >  > The following patches should allow selection of conservative, powersave, and
> >  > >  > >  > ondemand in the kernel configuration.
> >  > >  > >
> >  > >  > > This has been rejected several times already.
> >  > >  > > Ondemand and conservative isn't a viable governor for all cpufreq
> >  > >  > > implementations (ie, ones with high switching latencies).
> >  > >  >
> >  > >  > This piques my curiosity -- some governors don't work with some
> >  > >  > cpufreq implementations. Are those implementations in the kernel or in
> >  > >  > userspace? If in the kernel, then perhaps there should be some
> >  > >  > dependency expressed there in Kconfig between cpufreq implementation
> >  > >  > and the available governors
> >  > >
> >  > > it can't be solved that easily. powernow-k8 for example is fine to
> >  > > use with ondemand on newer systems, where the latency is low.
> >  > > On older models however, it isn't.
> >  > >
> >  > >  > > Also, see the
> >  > >  > > comment in the Kconfig a few lines above where you are adding this.
> >  > >  >
> >  > >  > Are these governors unfixable? If
> >  > >
> >  > > tbh, I've forgotten the original issues that caused the comment
> >  > > to be placed there. Dominik ?
> >  >
> >  > Not unfixable, but: cpufreq is currently[*] built around the assumption that
> >  > at least one governor is correctly initialized or can be brought to work
> >  > when a CPU is registered with the cpufreq core.
> >
> > It would have to take something fairly spectacular though for performance or
> > powersave to fail registration. Can you remember why we chose not to allow those?
>
> performance _is_ allowed; powersave would be possible -- but then those who
> accidentally enable it on elanfreq might wait 100 times as long for the
> system to boot, with gx-suspmod it might even be 255 times as long -- okay,
> by default it's just 20 times as long, but still...

I agree!

Let a stable governor like performance or userspace be the default to
get the cpufreq up and running during boot up, and later on have some
init script switch
to a preferred governor like powersave/ondemand/conservative.

Changing governor is just a matter of loading the appropriate module
and echoing the appropriate value into
/sys/devices/*/cpufreq/scaling_governor. Hardly takes any time.

William, Is there a specific reason why you would want
powersave/ondemand/conservative to be activate during the system boot
up?

>
>         Dominik
> -
Regards
gautham.

Re: [RFC] [PATCH] cpufreq: allow full selection of default governors

[William Heimbigner]

On Fri, 27 Apr 2007, Gautham Shenoy wrote:
> On 4/27/07, Dominik Brodowski <linux@dominikbrodowski.net> wrote:
>>  On Fri, Apr 27, 2007 at 02:09:57AM -0400, Dave Jones wrote:
>> >  On Thu, Apr 26, 2007 at 09:54:10PM -0400, Dominik Brodowski wrote:
>> > >  On Tue, Apr 24, 2007 at 08:03:27PM -0400, Dave Jones wrote:
>> > > >  On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote:
>> > > > >  On 4/24/07, Dave Jones <davej@redhat.com> wrote:
>> > > > > >  On Tue, Apr 24, 2007 at 09:03:23PM +0000, William Heimbigner 
>> > > > > >  wrote:
>> > > > > > >  The following patches should allow selection of conservative, 
>> > > > > > >  powersave, and
>> > > > > > >  ondemand in the kernel configuration.
>> > > > > > 
>> > > > > >  This has been rejected several times already.
>> > > > > >  Ondemand and conservative isn't a viable governor for all 
>> > > > > >  cpufreq
>> > > > > >  implementations (ie, ones with high switching latencies).
>> > > > > 
>> > > > >  This piques my curiosity -- some governors don't work with some
>> > > > >  cpufreq implementations. Are those implementations in the kernel 
>> > > > >  or in
>> > > > >  userspace? If in the kernel, then perhaps there should be some
>> > > > >  dependency expressed there in Kconfig between cpufreq 
>> > > > >  implementation
>> > > > >  and the available governors
>> > > > 
>> > > >  it can't be solved that easily. powernow-k8 for example is fine to
>> > > >  use with ondemand on newer systems, where the latency is low.
>> > > >  On older models however, it isn't.
>> > > > 
>> > > > > >  Also, see the
>> > > > > >  comment in the Kconfig a few lines above where you are adding 
>> > > > > >  this.
>> > > > > 
>> > > > >  Are these governors unfixable? If
>> > > > 
>> > > >  tbh, I've forgotten the original issues that caused the comment
>> > > >  to be placed there. Dominik ?
>> > > 
>> > >  Not unfixable, but: cpufreq is currently[*] built around the 
>> > >  assumption that
>> > >  at least one governor is correctly initialized or can be brought to 
>> > >  work
>> > >  when a CPU is registered with the cpufreq core.
>> > 
>> >  It would have to take something fairly spectacular though for 
>> >  performance or
>> >  powersave to fail registration. Can you remember why we chose not to 
>> >  allow those?
>>
>>  performance _is_ allowed; powersave would be possible -- but then those
>>  who
>>  accidentally enable it on elanfreq might wait 100 times as long for the
>>  system to boot, with gx-suspmod it might even be 255 times as long --
>>  okay,
>>  by default it's just 20 times as long, but still...
>
> I agree!
>
> Let a stable governor like performance or userspace be the default to
> get the cpufreq up and running during boot up, and later on have some
> init script switch
> to a preferred governor like powersave/ondemand/conservative.
>
> Changing governor is just a matter of loading the appropriate module
> and echoing the appropriate value into
> /sys/devices/*/cpufreq/scaling_governor. Hardly takes any time.
>
> William, Is there a specific reason why you would want
> powersave/ondemand/conservative to be activate during the system boot
> up?
>

Specific reason:
Powersave would be useful for preserving battery life / keeping the CPU cool.

Secondary reason: Is there any reason why powersave would be any more 
problematic than performance?

What about conservative? Would that be problematic?

It's been explained that ondemand could be problematic in computers which don't 
support low-latency transitions, but conservative fixes that.

If performance sends a command to cpufreq to use the highest frequency, and 
powersave sends a command to cpufreq to use the lowest frequency, can someone 
explain to me how performance can possibly safer than powersave?

William Heimbigner
icxcnika@mar.tar.cc