+ Rafael [corrected email addr] On 14 August 2014 15:57, Ashwin Chaugule <ashwin.chaugule@xxxxxxxxxx> wrote: > > Hello, > > Apologies in advance for a lengthy cover letter. Hopefully it has all the > required information so you dont need to read the ACPI spec. ;) > > This patchset introduces the ideas behind CPPC (Collaborative Processor > Performance Control) and implements support for controlling CPU performance > using the existing PID (Proportional-Integral-Derivative) controller (from > intel_pstate.c) and some CPPC semantics. > > The patchwork is not a final proposal of the CPPC implementation. I've had > to hack some sections due to lack of hardware, details of which are in the > Testing section. > > There are several bits of information which are needed in order to make CPPC > work great on Linux based platforms and I'm hoping to start a wider discussion on > how to address the missing bits. The following sections briefly introduce CPPC > and later highlight the information which is missing. > > More importantly, I'm also looking for ideas on how to support CPPC in the short > term, given that we will soon be seeing products based on ARM64 and X86 which > support CPPC.[1] Although we may not have all the information, we could make it > work with existing governors in a way this patchset demonstrates. Hopefully, > this approach is acceptable for mainline inclusion in the short term. > > Finer details about the CPPC spec are available in the latest ACPI 5.1 > specification.[2] > > If these issues are being discussed on some other thread or elsewhere, or if > someone is already working on it, please let me know. Also, please correct me if > I have misunderstood anything. > > 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: > > * Platform enumerates supported performance range to OS > > * OS requests desired performance level over some time window along > with min and max instantaneous limits > > * Platform is free to optimize power/performance within bounds provided by OS > > * Platform provides telemetry back to OS on delivered performance > > Communication with the OS is abstracted via another ACPI construct called > Platform Communication Channel (PCC) which is essentially a generic shared > memory channel with doorbell interrupts going back and forth. This abstraction > allows the “platform” for CPPC to be a variety of different entities – driver, > firmware, BMC, etc. > > CPPC describes the following registers: > > * HighestPerformance: (read from platform) > > Indicates the highest level of performance the processor is theoretically > capable of achieving, given ideal operating conditions. > > * Nominal Performance: (read from platform) > > Indicates the highest sustained performance level of the processor. This is the > highest operating performance level the CPU is expected to deliver continuously. > > * LowestNonlinearPerformance: (read from platform) > > Indicates the lowest performance level of the processor with non- linear power > savings. > > * LowestPerformance: (read from platform) > > Indicates the lowest performance level of the processor. > > * GuaranteedPerformanceRegister: (read from platform) > > Optional. If supported, contains register to read the current guaranteed > performance from. This is current max sustained performance of the CPU taking > into account all budgeting constraints. This can change at runtime and is > notified to the OS via ACPI notification mechanisms. > > * DesiredPerformanceRegister: (write to platform) > > Register to write desired performance level from the OS. > > * MinimumPerformanceRegister: (write to platform) > > Optional. This is the min allowable performance as requested by the OS. > > * MaximumPerformanceRegister: (write to platform) > > Optional. This is the max allowable performance as requested by the OS. > > * PerformanceReductionToleranceRegister (write to platform) > > Optional. This is the deviation below the desired perf value as requested by the > OS. If the Time window register(below) is supported, then this value is the min > performance on average over the time window that the OS desires. > > * TimeWindowRegister: (write to platform) > Optional. The OS requests desired performance over this time window. > > * CounterWraparoundTime: (read from platform) > Optional. Min time before the performance counters wrap around. > > * ReferencePerformanceCounterRegister: (read from platform) > > A counter that increments proportionally to the reference performance of the > processor. > > * DeliveredPerformanceCounterRegister: (read from platform) > > Delivered perf = reference perf * delta(delivered perf ctr)/delta(ref perf ctr) > > * PerformanceLimitedRegister: (read from platform) > > This is set by the platform in the event that it has to limit available > performance due to thermal or budgeting constraints. > > * CPPCEnableRegister: (read/write from platform) > > Enable/disable CPPC > > * AutonomousSelectionEnable: > > Platform decides CPU performance level w/o OS assist. > > * AutonomousActivityWindowRegister: > > This influences the increase or decrease in cpu performance of the platforms > autonomous selection policy. > > * EnergyPerformancePreferenceRegister: > > Provides a energy or perf bias hint to the platform when in autonomous mode. > > * Reference Performance: (read from platform) > > Indicates the rate at which the reference counter increments. > > > Whats missing in CPPC: > ===================== > > Currently CPPC makes no mention of power. However, this could be added in future > versions of the spec. > e.g. although CPPC works off of a continuous range of CPU perf levels, we could > discretize the scale such that we only extract points where the power level changes > substantially between CPU perf levels and export this information to the > scheduler. > > Whats missing in the kernel: > ============================ > > We may have some of this information in the scheduler, but I couldn't see a good way > to extract it for CPPC yet. > > (1) An intelligent way to provide a min/max bound and a desired value for CPU > performance. > > (2) A timing window for the platform to deliver requested performance within > bounds. This could be a kind of sampling interval between consecutive reads of > delivered cpu performance. > > (3) Centralized decision making by any CPU in a freq domain for all its > siblings. > > The last point needs some elaboration: > > I see that the CPUfreq layer allows defining "related CPUs" and that we can have > the same policy for CPUs in the same freq domain and one governor per policy. > However, from what I could tell, there are at least 2 baked in assumptions in > this layer which break things at least for platforms like ARM (Please correct me > if I'm wrong!) > > (a) All CPUs run at the exact same max, min and cur freq. > > (b) Any CPU always gets exactly the freq it asked for. > > So, although the CPUFreq layer is capable of making somewhat centralized cpufreq > decisions for CPUs under the same policy, it seems to be deciding things under > the wrong/inapplicable assumptions. Moreover only one CPU is in charge of > policy handling at a time and the policy handling is shifted to another CPU in the > domain, only if the former CPU is hotplugged out. > > Not having a proper centralized decision maker adversely affects power saving > possibilities in platforms that can't distinguish when a CPU requests a specific > freq and then goes to sleep. This potentially has the effect of keeping other > CPUs in the domain running at a much higher frequency than required, while the > initial requester is deep asleep. > > So, for point (3), I'm not sure which path we should take among the following: > > (I) Fix cpufreq layer and add CPPC support as a cpufreq_driver. (a) Change > every call to get freq to make it read h/w registers and then snap value back to > freq table. This way, cpufreq can keep its idea of freq current. However, this > may end up waking CPUs to read counters, unless they are mem mapped. (b) Allow > any CPU in the "related_cpus" mask to make policy decisions on behalf of > siblings. So the policy maker switching is not tied to hotplug. > > (II) Not touch CPUfreq and use the PID algorithm instead, but change the busyness > calculation to accumulate busyness values from all CPUs in common domain. > Requires implementation of domain awareness. > > (III) Address these issues in the upcoming CPUfreq/CPUidle integration layer(?) > > (IV) Handle it in the platform or lose out. I understand this has some potential > for adding latency to cpu freq requests so it may not be possible for all > platforms. > > (V) ..? > > For points (1) and (2), the long term solution IMHO is to work it out along with the > scheduler CPUFreq/CPUidle integration. But its not clear to me what would be > the best short term approach. I'd greatly appreciate any suggestions/comments. > If anyone is already working on these issues, please CC me as well. > > Test setup: > ========== > > For the sake of experiments, I used the Thinkpad x240 laptop, which advertises > CPPC tables in its ACPI firmware. The PCC and CPPC drivers included in this > patchset are able to parse the tables and get all the required addresses. > However, it seems that this laptop doesn't implement PCC doorbell and the > firmware side of CPPC. The PCC doorbell calls would just wait forever. Not sure > whats going on there. So, I had to hack it and emulate what the platform > would've done to some extent. > > I extracted the PID algo from intel_pstate.c and modified it with CPPC function > wrappers. It shouldn't be hard to replace PID with anything else we think is > suitable. In the long term, I hope we can make CPPC calls directly from the > scheduler. > > There are two versions of the low level CPPC accessors. The one included in the > patchset is how I'd imagine it would work with platforms that completely > implement CPPC in firmware. > > The other version is here [5]. This should help with DT or platforms with broken > firmware, enablement purposes etc. > > I ran a simple kernel compilation with intel_pstate.c and the CPPC modified > version as the governors and saw no real difference in compile times. So no new > overheads added. > I verified that CPU freq requests were taken by reading out the PERF_STATUS register. > > [1] - See the HWP section 14.4 http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3b-part-2-manual.pdf > [2] - http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf > [3] - https://plus.google.com/+TheodoreTso/posts/2vEekAsG2QT > [4] - https://plus.google.com/+ArjanvandeVen/posts/dLn9T4ehywL > [5] - http://git.linaro.org/people/ashwin.chaugule/leg-kernel.git/blob/236d901d31fb06fda798880c9ca09d65123c5dd9:/drivers/cpufreq/cppc_x86.c > > Ashwin Chaugule (3): > ACPI: Add support for Platform Communication Channel > CPPC: Add support for Collaborative Processor Performance Control > CPPC: Add ACPI accessors to CPC registers > > drivers/acpi/Kconfig | 10 + > drivers/acpi/Makefile | 1 + > drivers/acpi/pcc.c | 301 +++++++++++++++ > drivers/cpufreq/Kconfig | 19 + > drivers/cpufreq/Makefile | 2 + > drivers/cpufreq/cppc.c | 874 ++++++++++++++++++++++++++++++++++++++++++++ > drivers/cpufreq/cppc.h | 181 +++++++++ > drivers/cpufreq/cppc_acpi.c | 80 ++++ > 8 files changed, 1468 insertions(+) > create mode 100644 drivers/acpi/pcc.c > create mode 100644 drivers/cpufreq/cppc.c > create mode 100644 drivers/cpufreq/cppc.h > create mode 100644 drivers/cpufreq/cppc_acpi.c > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
