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

[Holger Macht]

On Mon 02. Jul - 20:37:55, S.Çağlar Onur wrote:
> 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. 

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.

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

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

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

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

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

Regards,
	Holger