Re: [PATCH] cpufreq: cppc: discard out-of-range delivered_perf samples

[Jeremy Linton <jeremy.linton@arm.com>]

Hi,

On 5/1/26 11:32 AM, Breno Leitao wrote:
> cppc_cpufreq_get_rate() derives delivered_perf as:
> 
>      delivered_perf = reference_perf * delta_delivered / delta_reference
> 
> over a short udelay()-bounded window between two cppc_get_perf_ctrs()
> calls. Per-read latency jitter on the underlying CPC register access
> can skew the ratio, occasionally producing delivered_perf >
> highest_perf. cppc_perf_to_khz() then linearly extrapolates above
> (nominal_perf, nominal_freq), so the value reported via
> /sys/.../cpufreq/cpuinfo_cur_freq exceeds cpuinfo_max_freq.
> 
> Observed on an arm64 host (governor=performance,
> cpuinfo_max_freq=3339 MHz): 15 back-to-back reads returned values
> between 2997 and 4230 MHz.
> 
> Treat an out-of-range sample as invalid and reuse the existing
> out_invalid_counters fallback, which returns the platform's
> desired_perf. This keeps cpuinfo_cur_freq within
> [0, cpuinfo_max_freq] without reporting a value the hardware did
> not deliver.
> 
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
>   drivers/cpufreq/cppc_cpufreq.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index 7e7f9dfb7a24c..dd92aa2bca464 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -814,6 +814,14 @@ static unsigned int cppc_cpufreq_get_rate(unsigned int cpu)
>   	if (!delivered_perf)
>   		goto out_invalid_counters;
>   
> +	/*
> +	 * Sampling jitter on the CPC counter pair can produce
> +	 * delivered_perf > highest_perf, which cppc_perf_to_khz() would
> +	 * extrapolate to a frequency above cpuinfo_max_freq. Discard.
> +	 */
> +	if (delivered_perf > cpu_data->perf_caps.highest_perf)
> +		goto out_invalid_counters;
> +

A little jitter over, is probably expected. If that is what is happening 
then clamping to highest_perf makes sense instead. But then, this is 
really a sampling problem so does it go away if you double the udelay 
slightly. Maybe the udelay value should be proportional to the 
reference_perf value?

>   	return cppc_perf_to_khz(&cpu_data->perf_caps, delivered_perf);
>   
>   out_invalid_counters:
> 
> ---
> base-commit: 26fd6bff2c050196005312d1d306889220952a99
> change-id: 20260501-cur_freq-fix-d569cf1d1052
> 
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
> 
>