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

Danny Kukawka danny.kukawka at web.de
Mon Jul 2 10:55:45 PDT 2007


On Montag, 2. Juli 2007, Holger Macht wrote:
> 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.

Then may rename the addon to CPU addon. I see no problem to add this methodes 
to the addon, it has at least something to do with CPU and reduce power 
consumtion. But I have no problem to start a powermanagement addon or 
something like that, but it would may interfer with the CPU Freq addon.

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

IMO you can simply let pm-utils as it is. Simly call this via HAL and if a 
desktop addon would like to add a expert mode to change this setting or some 
of them, the addon can call these methodes after call SetPowerSave() on HAL 
to pm-utils.

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

Desktop machines with dynamic CPU Freq settings, but which don't want to use 
the other things pm-utils may set. It's simple: add this methodes give the 
user the control over the system. It would make it more transparent. 

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

Thats may the problem. I have to say: I don't know at the moment what pm-utils 
to if I call SetPowerSave on HAL without checking the code of pm-utils. And 
this is IMO bad.

> What I would like to see is maybe an additional addon containing all these
> settings. 

okay for me ... as said: pm-utils can call these methodes if this is what 
pm-utils should do ...

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

sounds good.

Danny

Danny


More information about the hal mailing list