Update on DeviceKit

[Holger Macht]

On Do 08. Mai - 16:52:42, Rob Taylor wrote:
> Holger Macht wrote:
> > On Thu 08. May - 16:10:59, Matthew Garrett wrote:
> >> On Thu, May 08, 2008 at 04:50:31PM +0200, Holger Macht wrote:
> >>
> >>> Hey, it's just an abstract interface. Every system, architecture or
> >>> distribution can do whatever they want behind the interface. It's just an
> >>> "the higher the value, the higher the performance, the higher the power
> >>> consumption". And that's generally true.
> >> Right, but what are you changing? Limiting the maximum frequency to 
> >> anything other than the hardware maximum wastes power (and prevents you 
> >> from getting at Intel's dynamic acceleration stuff). Changing the 
> >> governor to anything other than ondemand wastes power. With enough 
> >> understanding of the workload, you could play with the threshold values 
> >> - but that also requires knowledge of the hardware, and so making that 
> >> decision requires exposing enough information to the application that a 
> >> simple 0-100 scale doesn't make any sense.
> > 
> > No, if you have this information beforehand, you can something
> > special-trained behind the interface.
> 
> Putting policy behine a org.freedesktop.DeviceKit.Power.CPUFreq 
> interface sounds a bit wrong to me. I'd prefer to just have the 
> available kernel knobs exposed. Maybe it might actually make sense to 
> have org.freedesktop.DeviceKit.Powermanagement.Linux etc as different 
> kernels will expose different knobs. CPUFreq is already an unportable 
> interface, right?

That's what it is:

 http://people.freedesktop.org/~david/hal-spec/hal-spec.html#interface-cpufreq

If systems know the concept of governors, it's portable.

> 
> >> Really. You can't provide any useful interface to the hardware in this 
> >> way.
> > 
> > You can.
> > 
> > But discussion stops here. If we like to, we will provide code for a
> > org.freedesktop.DeviceKit.Power.CPUFreq. You're not the consumer of any of
> > those interfaces. The corresponding maintainers will be notified, so they
> > just can "take it or hate it".
> > 
> 
> FWIW, I think Matthew is right, a 0-100 scale really doesnt make any 
> sense. We've been talking a lot over the last year or so about what 
> interfaces it makes sense for the kernel to expose up to userland. In 
> terms of the CPU my feeling is that a latency-to-running and some policy 
> decisions (like whether to race-to-idle, which most systems want to do).
> 
> Its better to gradually introduce interfaces as the kernel exposes them 
> than to invent something that doesn't really make sense...
> 
> In fact, we should really get some input from people that work on server 
> power management and see what they'd like.

I don't expect desktop application to be so intelligent to care about all
different policy knobs a CPU might export. But they want to tune the
setting depending on AC or Battery. Then consider the 1-100 scale as just
two settings, "on AC" and "on battery". It's basically used as that these
days.

Regards,
	Holger