Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

[Arjan van de Ven <arjan@linux.intel.com>]

On 7/15/2013 12:59 PM, Peter Zijlstra wrote:
> On Sat, Jul 13, 2013 at 07:40:08AM -0700, Arjan van de Ven wrote:
>> On 7/12/2013 11:49 PM, Peter Zijlstra wrote:
>>>
>>> Arjan; from reading your emails you're mostly busy explaining what cannot be
>>> done. Please explain what _can_ be done and what Intel wants. From what I can
>>> see you basically promote a max P state max concurrency race to idle FTW.
>>
>>>
>>> Since you can't say what the max P state is; and I think I understand the
>>> reasons for that, and the hardware might not even respect the P state you tell
>>> it to run at, does it even make sense to talk about Intel P states? When would
>>> you not program the max P state?
>>
>> this is where it gets complicated ;-( the race-to-idle depends on the type of
>> code that is running, if things are memory bound it's outright not true, but
>> for compute bound it often is.
>
> So you didn't actually answer the question about when you'd program a less than
> max P state.
(oops missed this part in my previous reply)

so race to halt is all great, but it has a core limitation, it is fundamentally
assuming that if you go at a higher clock frequency, the code actually finishes sooner.
This is generally true for the normal "compute" kind of instructions, but
if you have an instruction that goes to memory (and misses caches), that is not the
case because memory itself does not go faster or slower with the CPU frequency.

so depending of the mix of compute and memory instructions, different tradeoffs
might be needed.

(for an example of this, AMD exposes a CPU counter for this as of recently and added
patches to "ondemand" to use it)