Re: [RFC v1] Tunable sched_mc_power_savings=n

[Andi Kleen <andi@firstfloor.org>]

Matthew Garrett wrote:
> On Fri, Jun 27, 2008 at 10:06:28AM +0200, Andi Kleen wrote:
> 
>> Ok distcc is a special case, but it doesn't apply to a lot of other
>> processes (do you really want your CPU to crank up for "updatedb" or
>> beagle or some backup job for example?)
> 
> If something's CPU-bound, then you almost certainly want to speed the 
> CPU up. There's no power advantage to leaving it at a low frequency. 

I'm not sure you can say it that certainly. While on many standalone systems
"race to idle" is the best strategy, there are cases where it is not
true.

For example if you're in a data center at a specific operating point and
you would need to crank up the air condition at significant power cost it might
be well better overall to force all servers to a lower operating point
and avoid that.

That said in general you all should have complained when ondemand behaviour
was introduced.

Also it's unclear that the general "race to idle" heuristic really
applies to the case of the "keep sockets idle" power optimization
that started this thread.

Usually package C states bring much more than core C states
and keeping another package completely idle saves likely
more power than the power cost of running something a little
bit slower on a package that is already busy on another core.

I still think using nice levels for this is reasonable.

-Andi