CPU Speed in HAL

[Timo Hoenig]

Hi,

On Fri, 2005-11-25 at 15:03 +0000, Richard Hughes wrote:
> On Fri, 2005-11-25 at 15:15 +0100, Danny Kukawka wrote:
> > On Friday 25 November 2005 12:10, Richard Hughes wrote:

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

Extra complexity:  No. You're just shifting the complexity into HAL.

Configuration: No.  Just have a look at the NM approach.  You're not even
able to configure something.

For the concrete example of frequency scaling:  the powersave daemon is not
required to be configured 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. 
> 
> But reading is useless without being able to change the value.

If this is you're point of view, HAL offers way to many useless keys,
don't you think so?  A lot of information HAL provides is read-only.

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

Echoing some stuff to some interface.  Exactly.  Have you ever tried to
implement a proper frequency scaling policy for SMP and multicore
machines?

[...]

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

Yes, and still valid.

> More daemons to configure, more complicated interactions between daemons.

Things do not get easier by simply globing them together into one large
piece.

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

But supposing to put all this stuff into HAL you're doing exactly this.
It's getting a third leg which does power management.

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

With the experiences we have made over the last years you're lost
without a proper power management daemon.  And: things do not seem to
settle.

Thanks to DBUS interfaces of a daemon you won't have to setuid anything.

[...]

> > > 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 on-demand governor just became usable over the last few months.
Before this, you had the choice either to use a user space application
which did the logic (sigh, yepp, powersaved does this very fine, but
on-demand governor is default nowadays) or switch the frequency
manually.

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

Just a note: Intel Yonah.

Multicore is the future for mobile computing, too.  Picture it:  At home
you're able to run at full speed, two cores.  On the road you simply
switch off one core and scale down the active one to low speed.  Sexy.

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

Yepp.

CPU frequency scaling on multicore and SMP is no bed of roses, yet.

[...]

Having HAL becoming the 'all-in-one device suitable for every purpose'
scares me.

Once we can collate things of a specific and complex topic such as
networking, power management, printer management it is reasonable to
have those jobs handled by daemons, not by our beloved Hardware
Abstraction Layer.

I certainly see the points where g-p-m runs into blind alleys because it
lacks root privileges to set kernel interfaces.  But putting all these
things into HAL is just not the way to go.

> Richard.

Enjoy,

   Timo