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

[William Heimbigner <icxcnika@mar.tar.cc>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/