lkml.org 
[lkml]   [2012]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] x86,sched: Fix sched_smt_power_savings totally broken
From
Date
On Mon, 2012-01-09 at 21:33 +0530, Vaidyanathan Srinivasan wrote:

> Yes, based on the architecture and topology, we do have two sweet
> spots for power vs performance trade offs. The first level should be
> to reduce power savings with marginal performance impact and second
> one will be to go for the most aggressive power savings.

Colour me unconvinced, cache heavy workloads will suffer greatly from
your 1.

> The first one should generally be recommended as default to have
> a right balance between performance and power savings, while the
> second one should be used for reducing power consumption on
> unimportant workloads or under certain constraints.
>
> Some example policies:
>
> sched_powersavings=1:
>
> Enable consolidation at MC level
>
> sched_powersavings=2:
>
> Enable aggressive consolidation at MC level and SMT level if
> available. In case arch can benefit from cross node
> consolidation, then enable it.

You fail for mentioning MC/SMT..

> Having the above simple split in policy will enable wide adoption
> where the first level can be a recommended default. Having just
> a boolean enable/disable will mean the end-user will have to decide
> when to turn on and later off for best workload experience.

Picking one of two states is too hard, hence we given them one of three
states to pick from.. How does that make sense?

> Just similar to cpufreq policy of performance, ondemand and powersave.
> They have their unique use cases and this design choice helps us ship
> ondemand as default.

You fail for thinking having multiple cpufreq governors is a good thing.
The result is that they all suck.


\
 
 \ /
  Last update: 2012-01-09 17:15    [W:0.082 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site