Hi Peter, On 15 August 2014 10:07, Peter Zijlstra <pet...@infradead.org> 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. > >> Or even in the case of >> intel_pstate, if you map Desired to PERF_CTL and get value of >> Delivered by using aperf/mperf ratios (as my experimental driver >> does), then we can still maintain the existing system performance. It >> seems like if an OS can make use of the additional information then it >> should be net win for overall power savings and performance >> enhancement. Also, using the CPPC descriptors, we should be able to >> have one driver across X86 and ARM64. (possibly others too.) > > Yikes, so aaargh64 will go do creative power management too? Nice use or aargh. ;) Strangely hadn't seen that before. > > And worse; it will go do ACPI? Welcome to the world of guaranteed BIOS > fail :-( ACPI or not, I think leads to a rather different kind of debate. :) If all ARM implementations could include the CP15 equivalents of the CPPC MSRs that Intel has, then we wouldn't need this CPPC table. But that'll remain a pipe dream. So I'd prefer to think of CPPC as a simple wrapper of registers descriptions which allows implementations to choose how and where to get their CPPC information. However they choose to implement the registers, I think theres a lot of potential power savings and performance optimization on the table which can be acquired through CPPC. Given the platforms some amount of freedom to optimize things in a platform specific way helps them differentiate themselves (a key thing with ARM esp.) and keeping the idea of CPU performance abstract rather than tied to Frequency should help to keep things unified in the OS, so we avoid the driver bloat that ARM historically has had. Cheers, Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
