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

[S.Çağlar Onur]

Hi;

02 Tem 2007 Pts tarihinde, Holger Macht şunları yazmıştı: 
> Sorry for replying not earlier...

Thanks for your comments :)

> I'm not sure if the power sched settings fit into the CPUFreq addon. In
> fact, it actually has nothing to do with CPUFreq at all, except that it
> also deals with some kind of CPU settings.
>
> The reason why the CPUFreq addon is actually part of HAL is actually
> because it contains logic in the first place, and secondly, because it
> needs code to run all the time when thinking at the userspace governor.

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. 

> On the other side, all the powersave settings contained in pm-utils
> low-power method are simple scripts which need to run at a specific time
> and terminate after doing their job. All the individual settings are small
> enough to be summarized into one single method IMHO.
>
> My personal opinion is that you don't need the individual settings
> contained in pm-utils exported to the desktop. I can't tell if somebody
> needs them...and in fact it would be a real mistake to put them inside a
> GUI in GNOME or KDE IMHO.

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

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

> What I would like to see is maybe an additional addon containing all these
> settings. And it would also be good to use the infrastructure provided by
> the CPUFreq addon for this (all the dbus_* methods for instance). At a
> minimum, the functions/D-BUS methods provided in the patch need a proper
> prefix/infix and need to be put to a different source file (I will comment
> on other smaller issues in the patch as soon as we've sorted out
> everything).
>
> How does all this sound?

I think a powermanagement addon with lots of method will fit better :)

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/20070702/5c3f1b6e/attachment-0001.pgp