Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal
From: Arjan van de Ven
Date: Mon Jul 15 2013 - 16:42:04 EST
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)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/