Re: [PATCH v5] Force cppc_cpufreq to report values in KHz to fix user space reporting

["Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>]

On Tue, 2016-08-23 at 10:14 -0600, Al Stone wrote:
> > > 

[...]

> > In x86 when CPPC is used, the unit is really unit-less in CPPC
> > tables.
> > This means that cpu->perf_caps.highest_perf can be just 0xff,
> > instead
> > of some scaled cppc max performance corresponding to max MHZ the
> > processor can support. This allows the processor to cap at max
> > which it
> > can deliver.
> > Is this case not possible for ARM SoCs?
> > 
[...]
> If I understand the question properly, I don't think it matters, and
> I don't
> think that will work for x86 either.
> 
> This patch is meant to allow CPPC to continue operating solely based
> on the
> abstract scale provided by the ACPI tables; this should be true
> regardless
> of architecture.  Any actual processor performance changes are still
> guided
> solely by the CPPC scale provided in the tables, and not the values
> in the
> cpu->perf_caps struct.
> 
> Assuming I understand the kernel code, the values in cpu->perf_caps
> -- in this
> case -- are really just for reporting to user space via sysfs, which
> is the
> root of the problem: user space expects frequencies, and we have none
> when using
> CPPC so we have to provide an approximation.  In those circumstances,
> I think a
> value of 0xff would be kind of confusing in sysfs, since it's
> basically saying
> the CPU is operating at a frequency equal to the largest integer
> value.
> 
> To be fair, this is how the ARM processor implements CPPC; I have not
> examined
> in detail the newly submitted x86 patches to use CPPC so I cannot
> comment on
> those.  This patch was written well before those showed up.
Currently we are not using cppc-cpufreq driver, so not will not
directly impact (you are  not changing acpi-cpufreq source, which we
are using).
x86 has other way to get max/min cpufreq policy frequencies using MSRs.
So you may choose to ignore my comments here, as long as your changes
are limited to drivers/cpufreq/cppc_cpufreq.c

When you are doing:
policy->min = cpu->perf_caps.lowest_perf * cppc_dmi_max_khz / cpu-
>perf_caps.highest_perf;

Aren't you assuming that scale from max to min performance is only
related to frequency? It is possible that many points in between can be
same frequency with multiple voltages.
As per spec " The platform may choose to use a single metric such as
processor frequency, or it may choose to blend multiple hardware
metrics to create a synthetic measure of performance".

Thanks,
Srinivas 


>