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

[Holger Macht]

On Sun 17. Jun - 01:01:36, S.Çağlar Onur wrote:
> Hi;
> 
> 11 Haz 2007 Pts tarihinde, S.Çağlar Onur şunları yazmıştı: 
> > Following patch tries to add GetSchedPowerSavings/SetSchedPowerSavings
> > methods to cpufreq-addon.
> >
> > This patch is nothing but a "i want to hear your comments one" :), so if
> > this is acceptable i want to provide another patch in future to introduce
> > CPU online/offlining with HAL, so kpowersave/gnome-power-manager can
> > provide these features to users also.
> >
> > For reference, "power savings sched policy" introduces following
> > [@http://kernelnewbies.org/Linux_2_6_18]
> 
> David, could you please share your opinions also? I don't want to try to 
> implement an unacceptable, not needed or not usefull feature set :)
> 
> What i'm trying to do is a set of new methods for HAL's PowerManagement 
> capabilities (and maybe a seperate powermanagement addon) so kpowersave/g-p-m 
> or any other tool can provide this facilities to users like what intel's 
> powertop suggestions provides (closing not needed bluetooth 
> interfaces/offlining CPU's/setting power management options of wireless 
> cards/changing scheduler behaviours etc.)

Sorry for replying not earlier...

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.

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.

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.

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?

Regards,
	Holger