CPU Speed in HAL

[Richard Hughes]

On Fri, 2005-11-25 at 15:15 +0100, Danny Kukawka wrote:
> 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! 

Heh. Not sure why you cc'd Matthias, but I'll leave the CC.

> > 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? 

Extra complexity and dependencies. Yet another daemon to configure.

> > 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. 

But reading is useless without being able to change the value.

> > 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)

Not really. Take cpufreq applet as the example.

At startup it reads in the allowed frequencies (one read) and sets up
the right-click menu. When the user clicks one frequency icon a single
call is made to HAL to change the frequency. The applet says simple, and
doesn't start dabbling with the hardware directly.

> Nobody would change to this workflow with additional dependencies. I see no 
> reason to implement this (not trivial) cpufreq task to HAL.

It's not actually /that/ complicated. Reading a couple of files in sys
or proc and then echoing stuff to them with new values.

>  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. 

So? HAL doesn't require split-second accuracy of the current frequency
-- polling one file every 60 seconds is probably okay. Or we could use
another method GetCPUFrequency to avoid having to do any polling.

> 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.

Ohh, I agree the battery stuff is only now starting to settle down. It
is really useful, and probably the best power information source for
APM, ACPI and PMU there is (in my biased opinion). Battstat has already
switched to the HAL backend source over it's custom acpi/pmu solution.

> 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.

This is an old argument. More daemons to configure, more complicated
interactions between daemons. It's not like I'm proposing a power
management 'stack' in HAL, it's just the little addons and probers and
the like that make HAL so powerful.

> 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) 

I don't need a whole powersave daemon, I just need a way to change the
cpu frequency from session-space (without ugly hacks such as setting an
applet setuid).

If the consensus is that HAL shouldn't deal with cpufreq directly, then
I'll look at how easily HAL can interact with powersaved or cpufreqd in
the same way as we currently hibernate, using scripts. This does limit
the API we can present, and may make it unsuitable for things like
cpufreq applet and g-p-m to make full use of the hardware capability.

> > 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.

Or we can use a GetCPUFrequency call like we do for GetLCDBrightness
(which can change from under our feet, just like with the ondemand
option)

> > 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.

Well, lots of people seem to use cpufreq applet to change the frequency
manually (based from screenshots of desktops on p.g.o). Maybe you are
correct that setting the kernel policy to onDemand is the correct way
(i.e. hook into SetLowPowerMode) and that session-space shouldn't touch
the hardware at all.

> > 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 ...

Sure, but this could come in time. I'm guessing most people that change
the cpufrequency on a regular basis are sitting on a uniprocessor
laptop, rather than a 4-way dual-core server. But there is no reason why
this couldn't apply to the smp case. I wasn't aware you could use
cpufreq on SMP, but this is based on old kernel knowledge so may be
wrong now.

> 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. 

But just like with the battery.* information, there are ofter other
users that could use this information and methods to reduce code, reduce
errors and have one place where hardware quirks can be put.

There is no way an applet should have to be setuid just to do something
very simple with the hardware, and for a simple power management session
daemon to replicate 99% of the cpufreq backend code just to spin-down a
CPU to a preset limit.
This doesn't just apply to specific applets and g-p-m, it applies to any
future power-management daemon, program, script or whatever.

I know we differ in our thoughts of power-management (i.e. whether HAL
should abstract specific hardware to a generic dbus interface), but I do
appreciate the feedback. I'm just a new linux developer who sees stuff
and says (maybe naively) "that sucks, we could do that better" when
nobody has challenged it in years.

Richard.