Re: [PATCH] cpufreq_ondemand

[Dominik Brodowski <linux@dominikbrodowski.de>]

On Wed, Oct 20, 2004 at 05:03:45PM -0400, Len Brown wrote:
> On Wed, 2004-10-20 at 10:30, Dominik Brodowski wrote:
> > On Wed, Oct 20, 2004 at 03:35:35AM -0400, Len Brown wrote:
> 
> > > The question is what POLICY we're trying to implement.
> > 
> > This is why there may be DIFFERENT policies a.k.a. governors in
> > cpufreq.
> ....
> > 
> > Put it in userspace, and let it ask the cpufreq core in the kernel to
> > use a specific governor or another depending on what you want. That's
> > what certain userspace daemons / scripts already do, btw.
> 
> Processors are not the only devices with power management.  When a
> device driver, say USB, or any ACPI or PCI power-managed device,
> recognizes that its device is idle, who does it ask to find out what
> power state to put the hardware in?  Today there is nobody to tell it
> what to do.

Something like sysfs' "detach_state" comes to my mind...

> The user's global desired power policy needs to be represented in the
> kernel where all devices can get at it so they can make low-latency
> policy-based decisions.  It isn't clear that the cpufreq multiple
> governor implementation model would work well for the system as whole.

The question is how much policy we want in the kernel instead of in
userspace. The actual implementation (i.e. fast transitions to idle states)
must be in the kernel, of course. However the policy decision of whether to
do such idling can and IMHO should be done in userspace.

My $0.02,

	Dominik