lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAJ5Y-ebgJi8Ngxg1X+h7KMundGZPFhYC0hr0Sog6htj=czszgQ@mail.gmail.com> Date: Thu, 14 Aug 2014 17:56:10 -0400 From: Ashwin Chaugule <ashwin.chaugule@...aro.org> To: Peter Zijlstra <peterz@...radead.org> Cc: lkml <linux-kernel@...r.kernel.org>, Catalin Marinas <catalin.marinas@....com>, Mike Turquette <mike.turquette@...aro.org>, Morten Rasmussen <morten.rasmussen@....com>, arjan@...ux.intel.com, mingo@...nel.org, len.brown@...el.com, rjw@...ysocki.net, "linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>, Arnd Bergmann <arnd@...db.de>, linux-acpi@...r.kernel.org, cpufreq@...r.kernel.org, Patch Tracking <patches@...aro.org>, dirk.brandewie@...il.com Subject: Re: [RFC 0/3] Experimental patchset for CPPC Hi Peter, On 14 August 2014 16:51, Peter Zijlstra <peterz@...radead.org> wrote: > On Thu, Aug 14, 2014 at 03:57:07PM -0400, Ashwin Chaugule wrote: >> >> >> What is CPPC: >> ============= >> >> CPPC is the new interface for CPU performance control between the OS and the >> platform defined in ACPI 5.0+. The interface is built on an abstract >> representation of CPU performance rather than raw frequency. Basic operation >> consists of: > > Why do we want this? Typically we've ignored ACPI and gone straight to > MSR access, intel_pstate and intel_idle were created especially to avoid > ACPI, so why return to it. > > Also, the whole interface sounds like trainwreck (one would not expect > anything else from ACPI). > > So _why_? The overall idea is that tying the notion of CPU performance to CPU frequency is no longer true these days.[1]. So, using some direction from an OS , the platforms want to be able to decide how to adjust CPU performance by using knowledge that may be very platform specific. e.g. through the use of performance counters, thermal budgets and other system specific constraints. So, CPPC describes a way for the OS to request performance within certain bounds and then letting the platform optimize it within those constraints. Expressing CPU performance in an abstract way, should also help keep things uniform across various architecture implementations. I dont see CPPC as necessarily an ACPI specific thing. If the platform can provide the information which CPPC lays out via MSRs or other system IO, then the higher algorithms should still work. The CPPC table itself is nothing but register descriptions. It describes how and where to access the registers. The registers can be anything, from system I/O addresses, MSRs, CP15, or Mailbox type addresses(PCC). CPPC doesn't even you tell what to do with that information. So its really just a descriptor. If you see the example in [2], the aperf and mperf reads directly go to MSR addresses as parsed from the tables. If the platform does not have ACPI, but knows how to provide the same information, then it can directly read its MSRs or other sys regs. e.g. as in the case of core_get_{min,max}_pstate(), which are used to get highest and lowest performance values. But I think the problem is that we dont have an algorithm that can make use of the information that CPPC supported platforms can provide, nor can we provide CPPC related information back to the platform. Cheers, Ashwin [1]- https://plus.google.com/+ArjanvandeVen/posts/dLn9T4ehywL [2] - http://git.linaro.org/people/ashwin.chaugule/leg-kernel.git/blob/236d901d31fb06fda798880c9ca09d65123c5dd9:/drivers/cpufreq/cppc_x86.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists