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

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

[Breno Leitao]

Hello Jeremy,

On Fri, May 01, 2026 at 12:41:45PM -0500, Jeremy Linton wrote:
> A little jitter over, is probably expected. If that is what is happening
> then clamping to highest_perf makes sense instead.

Based on my analysis of the code, interrupts appear to remain enabled
during the delay, which could introduce significant jitter if an IRQ
fires during that window.

I'd be interested in testing this under an IRQ storm to quantify the
actual impact on the measurements.

> 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?

That's a reasonable approach. What would you suggest for the
implementation?

I considered making it a kernel or module parameter, but I'm not certain
that's the best solution, since the "user" might not know what to
set/use.

Thanks for your review,
--breno

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

[Jie Zhan]

On 5/2/2026 12: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.
Hi Breno,

Frequency sampling discrepancy through 'cpuinfo_cur_freq' in the
cppc_cpufreq driver has been an issue discussed for a very long time.

If the CPPC feedback counters are FFH on your platform, can you have a look
at [1] and see if that helps?

Thanks,
Jie
> 
> 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(+)
> 
...

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

[Breno Leitao]

Hello Jie,

On Fri, May 08, 2026 at 11:23:18AM +0800, Jie Zhan wrote:
> On 5/2/2026 12: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.
> Hi Breno,
> 
> Frequency sampling discrepancy through 'cpuinfo_cur_freq' in the
> cppc_cpufreq driver has been an issue discussed for a very long time.

Thanks for the heads-up.

> If the CPPC feedback counters are FFH on your platform, can you have a look
> at [1] and see if that helps?

Have you forgot to get the [1] link here?

Thanks for looking at this,
--breno

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

[Jie Zhan]

On 5/8/2026 4:17 PM, Breno Leitao wrote:
> Hello Jie,
> 
> On Fri, May 08, 2026 at 11:23:18AM +0800, Jie Zhan wrote:
>> On 5/2/2026 12: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.
>> Hi Breno,
>>
>> Frequency sampling discrepancy through 'cpuinfo_cur_freq' in the
>> cppc_cpufreq driver has been an issue discussed for a very long time.
> 
> Thanks for the heads-up.
> 
>> If the CPPC feedback counters are FFH on your platform, can you have a look
>> at [1] and see if that helps?
> 
> Have you forgot to get the [1] link here?
Yeah, totally forgot, sorry!

[1] https://lore.kernel.org/lkml/20260410094145.4132082-1-zhangpengjie2@huawei.com/
> 
> Thanks for looking at this,
> --breno