CPU Speed in HAL

[Danny Kukawka]

On Friday 25 November 2005 12:10, Richard Hughes wrote:
> As most of you probably know, most new laptops can scale the speed of
> the cpu to save considerable amounts of power. Now I've persuaded my
> kernel to load the speedstep module, I've found my battery life
> *substantially* increases when I scale my CPU manually.

Welcome to the world of powermanagement! 

> CPU speed is usually taken care of by system daemons such as cpuspeed,
> cpufreqd, powernowd, speedy or by a setuid applet such as the cpufreq
> applet. 

What is the problem with a system daemon for this task? 

> What I'm proposing is that we move the raw information reporting 
> (from sysfs and procfs) into HAL. This means session programs such as 
> the cpufreq applet and g-p-m do not have to be set setuid to talk to the
> hardware. 

To *read* the information from sysfs or proc you don't need root rights. You 
can also read as user. 

> I appreciate there are already daemons that just sit and poll 
> the cpufreq hardware, which you can talk to in many different ways, but
> to make all the elements "just work" I think we need a really simple HAL
> API so that the cpufreq applet and g-p-m (and potentially other daemons)
> can take advantages of the abstraction.

I really see not "advantages of the abstraction"! The proc and mainly sysfs is 
well abstacted currently for cpufreq. There are already existing and well 
working daemons for this. Why should I change a exsting workflows from 
communicate with a existing daemon to:

client ---> HAL (--> read from kernel) --> client --> HAL --> set to kernel 
--> report back to daemon (+ invoke DBUS for communication)

Nobody would change to this workflow with additional dependencies. I see no 
reason to implement this (not trivial) cpufreq task to HAL. What's the 
problem that the daemons poll for information? If you want to provide current 
CPU freq with HAL you need to poll/read permanently from sys/proc to have 
always the correct cpufreq. You can have multiple changes in cpufreq per 
second. 

Remember the last discussion [1] about g-p-m and adding more powermanagement 
issues to HAL. There where also other opinions about this. I don't 
understand, why we should add more and more powermanagement task to HAL only 
because g-p-m needs them, IMO nobody else need them because there are already 
many well working solutions. We should concentrate on remove BUGS and make 
HAL more stable instead of add this really complex and big new part.

I'm not the only one who think powermanagement is, as already 
networkmanagement (with Networkmanager), a big block of tasks which should be 
moved to a extra solution/daemon or remain the exsting solutions.

If you need to talk via DBUS to get powermanagement tasks (which need root 
rights) there are IMO two ways:
* implement a powermanagement daemon with DBUS interface
* use a existing powermanagement daemon e.g. powersave which have a well 
defined DBUS interface (which is already available for SUSE, ALTLinux, 
Debian, Ubuntu, Gentoo and I think in the next weeks also for RedHat/Fedora) 

> What I'm proposing:
> On the CPU devices (which we have already for acpi) two additional keys:
> strlist	cpufreq.allowed_frequencies
> int	cpufreq.current_frequency

See above. If you use kernel ondemand governor you need to poll permanently to 
have this key actuall. Really bad.

> And one additional method.
> bool	o.fd.h.Device.SystemPowerManagement.SetCPUFrequency(int frequency)
>
> I'm not thinking of exporting stuff like the kernel cpufreq policy, or
> the voltage steps as this is either not required, or can be done at
> higher levels (such as manually with the applet and automatically with
> g-p-m).

Use the on-demand kernel governor and you never need to do this. And we don't 
need this in HAL.

> The method can be a simple script (like SetLCDBrightness) or a simple
> c-file (if we want to check that the frequency range is valid before we
> shunt it into sysfs or procfs) -- probably a good idea. All the patches
> are likely to be less than a few hundred lines of code.

I don't think so, this are not only "less than a few hundred lines of code" if 
you want implement this correctly with a well working userspace on demand 
solution. Only some point to think about in this context:
* multiprocessor machines
* dual or maybe multicore CPUs where you can change frequency per core or not 
(depends on CPU model)
* multiprocessor machines with dual or multicore ...

I'm completely opposed to this proposal. We should not integrate this to HAL. 
What is the next? Volume control via HAL? Merge NetworkManager back to HAL? 
Please don't implement all what you need in g-p-m in HAL. This is not the 
solution. 

Cheers,

Danny

[1] http://thread.gmane.org/gmane.comp.gnome.powermanager.devel/575