[PATCH] sched: mc/smt power savings sched policy

[S.Çağlar Onur]

Hi;

02 Tem 2007 Pts tarihinde, Holger Macht şunları yazmıştı: 
> > Aggreed, and in my opinion that kind of methods will best fit in seperate
> > powermanagement addon (or in pm-utils). I really don't care who provides
> > these, my only point is what is provided and current ones are not enough
> > to write a powermanagement software on top of HAL for example :P.
>
> If someone likes to write a powermanagement software/GUI that will be so
> detailed, then yes, HAL might not be sufficient. But in this case, maybe
> one should think about implementing the needed bits anyway.
>
> Don't get me wrong, I'm not completely against having the functionality in
> HAL, I'm just satisfied with the current situation and don't see any real
> use cases for this kind of detailed methods. Just thinking about that this
> shifts away more and more from the principle of abstraction.

I'm nearly agree with you :) but still i cannot imagine why providing more 
methods will hurt the abstraction concept of HAL at all. 

HAL will provide some logical PowerManagement methods (i agree with Richard 
here, one cannot simply provide all possible sysfs values for just providing. 
But i'm not convinced these examples are just some arbitrary sysfs values) to 
its users and applications will not deal with implementation details of this 
concept, they will just use needed methods for their purposes without knowing 
underlying implementation details and concepts. 

So my point of view providing some more methods for advanced powermanagement 
facilities are also makes an abstraction :)

And just for clearification i'm not saying lets remove SetLowPower and split 
it into hundread piece, I only mean providing additional advanced features 
can also be usefull (by the way with only SchedPowerSave [on core2duo] my 
battery extends ~10 min) and there may be potential users in our planet :P.

> > I'm still not sure why providing these with GUI is mistake, its true for
> > SchedPowerSavings its small enough, but what if i want to shutdown my
> > unneeded bluetooth interface or offlining my other CPU's, activating my
> > wireless card or my sound card's powersaving features :) ?
>
> Just commenting some of the bits you're mentioning here...
>
>  - Bluetooth interfaces should have some kind of autosuspend mechanism like
>    usb has (don't know if there are technical obstacles)?

I agree but currently they can't :(, but while searching i found Bluez 
provides "org.bluez.Adapter.SetMode" for this purpose but according to 
discussion its not recommended way, they say unplug the dongle if its a 
dongle or turn off the hardware switch if such switch exists :). But at least 
somebody else provides some methods for shuting down bluetooth interfaces 
without console :)

>  - We already discussed about offlining CPUs some time ago. What do you
>    expect of having the possibility of shutting down CPUs? Power savings?
>    You won't get them in the end.

Hmm, i'll search archives for this discussion, thanks for info.

>  - Generally, the hardware or the driver should be intelligent enough to
>    save as much power as possible when idle. If not idle, you want the job
>    done as fast as possible.

Totally agree with you.

>  - I can't imagine a use case where you want to enable the hardware's
>    power saving features of a _single_ device. Either you want to save as
>    much power as possible or you don't ;-)
>
> > > However, I'm don't feel in the position to be able to appoint to anyone
> > > at which point a policy setting is "unimportant" enough to not justify
> > > an own method. If something _is_ a policy setting, then it has the
> > > right to be controlled individually. Otherwise we would actually do
> > > some kind of policy via combining absolutely different setting to one
> > > single method at system level.
> >
> > I totaly agree, HAL must provide these as a seperate methods.
>
> Not against it, I just don't see no real need for it.

I don't really have specific use cases for your arguments. I only can say i 
want to shutdown my unsused bluetooth interface without dealing with modprobe 
blacklisting/without console tools or without some config file modification. 
All i want to shutdown that one if not used and make it online when i need 
it. 

One huge abstracted solution may not fit every need, for example i always 
disable laptop-mode cause it _may_ end up with data corruption because its 
delayed behaiour and this is unacceptable for me.

And these advanced feautures are really not that different from backlight 
methods, it all depends how you use it, sometimes i lower my backlight for 
powersaving purposes while on battery and sometimes i lower it cause my eyes 
start to hurts :)

I think its just about giving more control to users for their systems and let 
them decide what they want, so it seems my arguments are social ones :)

Cheers
-- 
S.Çağlar Onur <caglar at pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/hal/attachments/20070703/1c6ee9a5/attachment.pgp