Update on DeviceKit

[Rob Taylor]

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?

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

Thanks,
Rob