CPUFreq addon in HAL

[Holger Macht]

On Wed 05. Jul - 19:30:21, Kevin Ottens wrote:
> Le mercredi 5 juillet 2006 18:13, Holger Macht a écrit :
> > > Original, but why not after. It's original to have a fine grained control
> > > like this.
> >
> > I really don't understand what you are trying to say here ;-) Was it a
> > question or a statement? :-)
> 
> Yeah, missed a few words. It was more a statement. My point was more:
> I don't really see a use for such a fine grained control right now, but I'm 
> not necessarily against such a feature.
> 
> Btw, if you could provide a few use cases for this one you would make me 
> happy. ;-)

In general, there are three different policies one can chose from:

 1. Statically min frequency (corresponds to the powersave governor)
 2. Statically max frequency (corresponds to the performance governor)

 3. Dynamic frequency (ondemand or userspace governor)

In an ideal world, the the first two shouldn't be used at all. But at
least the performance governor is still used because you get a little bit
more performance in comparison with the dynamic policy. Particularly as
soon as you have many small processes running. The default dynamic setting
can be and was sufficient in most cases. But it's a too general setting
IMO. So to basically get rid of the two static policies, I'm doing a split
of the dynmaic policy into several parts.

The dynamic machanisms, either ondemand governor, conservative governor or
the userspace implementation etc. consist each of several different
settings and configuration options like at which load to switch up, how
many steps the mechanism should traverse until reaching max freq and so
on. The SetCPUFreqPerformance combines all these setting into one.

I will do a small comparison...

Two main situations where policies differ are

On AC power:
  You want to do dynamic frequency scaling, but It's not that important
  to reduce power consumption. You want to have the maximum performance as
  soon as you start a process but still want to reduce the power drain as
  soon as the system is idle. (e.g. because of thermal reasons). So you
  need a more aggressive dynamic CPU frequency scaling where you switch up
  sooner and more often. So for instance, you set the performance to 75.

On battery:
  The primary goal is to increase battery life. But you still want a job
  done as fast as possible as soon there is need to, for instance when
  compiling. So you might want a more tentative frequency
  adjustment. Performance maybe set to 25 in this case.

The reason why I chose such a fine grained range (from 1 to 100) is to get
an interface that is not limited to only one implementation. For the
CPUFreq case, one can image to have only five steps like min, low, medium,
high, max. But that's something the GUI can and should decide. It can map
these 100 steps to whatever it likes but I don't think that's the job of
the addon. And maybe some system (embedded?, whatever) likes to have a
completely other implementation with 20, 30, or even 100 steps but still
likes to take advantage of the common interface, it than wouldn't be
limited to a predefined range.

Additionally, if a policy decision maker (like a GUI) doesn't like to
touch the performance setting, it doesn't need to. It gets a good default
setting. The default is 50 and corresponds to a configuration which is
either the kernel default or which is tested to be stable and useful for
several years now in the userspace case.


Regards,
	Holger