lkml.org 
[lkml]   [2016]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v5] Force cppc_cpufreq to report values in KHz to fix user space reporting
Date
On Wednesday, July 20, 2016 03:10:04 PM Al Stone wrote:
> When CPPC is being used by ACPI on arm64, user space tools such as
> cpupower report CPU frequency values from sysfs that are incorrect.
>
> What the driver was doing was reporting the values given by ACPI tables
> in whatever scale was used to provide them. However, the ACPI spec
> defines the CPPC values as unitless abstract numbers. Internal kernel
> structures such as struct perf_cap, in contrast, expect these values
> to be in KHz. When these struct values get reported via sysfs, the
> user space tools also assume they are in KHz, causing them to report
> incorrect values (for example, reporting a CPU frequency of 1MHz when
> it should be 1.8GHz).
>
> The downside is that this approach has some assumptions:
>
> (1) It relies on SMBIOS3 being used, *and* that the Max Frequency
> value for a processor is set to a non-zero value.
>
> (2) It assumes that all processors run at the same speed, or that
> the CPPC values have all been scaled to reflect relative speed.
> This patch retrieves the largest CPU Max Frequency from a type 4 DMI
> record that it can find. This may not be an issue, however, as a
> sampling of DMI data on x86 and arm64 indicates there is often only
> one such record regardless. Since CPPC is relatively new, it is
> unclear if the ACPI ASL will always be written to reflect any sort
> of relative performance of processors of differing speeds.
>
> (3) It assumes that performance and frequency both scale linearly.
>
> For arm64 servers, this may be sufficient, but it does rely on
> firmware values being set correctly. Hence, other approaches will
> be considered in the future.
>
> This has been tested on three arm64 servers, with and without DMI, with
> and without CPPC support.
>
> Changes for v5:
> -- Move code to cpufreq/cppc_cpufreq.c from acpi/cppc_acpi.c to keep
> frequency-related code together, and keep the CPPC abstract scale
> in ACPI (Prashanth Prakash)
> -- Fix the scaling to remove the incorrect assumption that frequency
> was always a range from zero to max; as a practical matter, it is
> not (Prasanth Prakash); this also allowed us to remove an over-
> engineered function to do this math.
>
> Changes for v4:
> -- Replaced magic constants with #defines (Rafael Wysocki)
> -- Renamed cppc_unitless_to_khz() to cppc_to_khz() (Rafael Wysocki)
> -- Replaced hidden initialization with a clearer form (Rafael Wysocki)
> -- Instead of picking up the first Max Speed value from DMI, we will
> now get the largest Max Speed; still an approximation, but slightly
> less subject to error (Rafael Wysocki)
> -- Kconfig for cppc_cpufreq now depends on DMI, instead of selecting
> it, in order to make sure DMI is set up properly (Rafael Wysocki)
>
> Changes for v3:
> -- Added clarifying commentary re short-term vs long-term fix (Alexey
> Klimov)
> -- Added range checking code to ensure proper arithmetic occurs,
> especially no division by zero (Alexey Klimov)
>
> Changes for v2:
> -- Corrected thinko: needed to have DEPENDS on DMI in Kconfig.arm,
> not SELECT DMI (found by build daemon)
>
> Signed-off-by: Al Stone <ahs3@redhat.com>
> Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>

Applied.

Thanks,
Rafael

\
 
 \ /
  Last update: 2016-09-17 09:59    [W:0.096 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site