Re: [RFC 0/3] Experimental patchset for CPPC

[Ashwin Chaugule]

Hello,

On 15 August 2014 10:41, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> On Fri, Aug 15, 2014 at 10:37:32AM -0400, Ashwin Chaugule wrote:
>> On 15 August 2014 10:07, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>> > On Fri, Aug 15, 2014 at 09:08:50AM -0400, Ashwin Chaugule wrote:
>> >> If the OS only looks at Highest, Lowest, Delivered registers and only
>> >> writes to Desired, then we're not really any different than how we do
>> >> things today in the CPUFreq layer.
>> >
>> > The thing is; we're already struggling to make 'sense' of x86 as it
>> > stands today. And it looks like this CPPC stuff makes the behaviour even
>> > less certain.
>>
>> I think its still better than the "p-state" thing we have going today,
>> where the algorithms are making their decisions based on the incorrect
>> assumption that the CPU got what it requested for. (among other things
>> listed earlier.) CPPC at least gives you a guarantee that the
>> delivered performance will be within a range you requested. It can
>> even force the platform to deliver a specific performance value if you
>> choose over a specific time window.
>
> Maybe; the guarantee and interrupt on change might be useful indeed. But
> which ever way we need aperf/mperf ratios somewhere.

Right. Regarding aperf/mperf; some ARMs will re-use existing
performance counters, while others may have dedicated registers to
count the equivalent. So I'm suggesting the use of the CPPC
descriptors to unify the various implementations. In CPPC terms, aperf
maps to the Delivered ctr and mperf maps to the Nominal ctr. Until we
have rest of the plumbing in the scheduler to make use of the other
CPPC specified regs, we can at least start off with having a common
lower level driver as suggested in this patchset and reusing the PID
controller as the "governor". Thats the only one that actually makes
use of aperf/mperf today AFAIK. The driver can then be modified to
include the Freq domain awareness as well, so that it works well on
non-X86 platforms. Unless anyone strongly thinks that we should fix
the shortcomings in the CPUfreq layer(broken pstate and freq domain
assumptions) rather than enhancing PID? Thoughts?


Cheers,
Ashwin
--
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/