[PATCH v3] cpufreq: CPPC: Update FIE arch_freq_scale in ticks for non-PCC regs
Jie Zhan
zhanjie9 at hisilicon.com
Thu Nov 13 00:18:35 PST 2025
On 11/13/2025 4:04 PM, Beata Michalska wrote:
> On Tue, Nov 11, 2025 at 07:30:09PM +0800, Jie Zhan wrote:
>>
>>
>> On 11/11/2025 12:49 AM, Beata Michalska wrote:
>>> Hi Jie,
>>> On Tue, Nov 04, 2025 at 02:50:39PM +0800, Jie Zhan wrote:
>>>> Currently, the CPPC Frequency Invariance Engine (FIE) is invoked from the
>>>> scheduler tick but defers the update of arch_freq_scale to a separate
>>>> thread because cppc_get_perf_ctrs() would sleep if the CPC regs are in PCC.
>>>>
>>>> However, this deferred update mechanism is unnecessary and introduces extra
>>>> overhead for non-PCC register spaces (e.g. System Memory or FFH), where
>>>> accessing the regs won't sleep and can be safely performed from the tick
>>>> context.
>>>>
>>>> Furthermore, with the CPPC FIE registered, it throws repeated warnings of
>>>> "cppc_scale_freq_workfn: failed to read perf counters" on our platform with
>>>> the CPC regs in System Memory and a power-down idle state enabled. That's
>>>> because the remote CPU can be in a power-down idle state, and reading its
>>>> perf counters returns 0. Moving the FIE handling back to the scheduler
>>>> tick process makes the CPU handle its own perf counters, so it won't be
>>>> idle and the issue would be inherently solved.
>>>>
>>>> To address the above issues, update arch_freq_scale directly in ticks for
>>>> non-PCC regs and keep the deferred update mechanism for PCC regs.
>>> Something about it just didn’t sit right with me, and apparently, it needed some
>>> time to settle down - thus the delay.
>>>
>>> It all looks sensible though it might be worth to considered applying
>>> the change on a per-CPU basis, as, in theory at least, different address
>>> spaces are allowed for different registers (at least according to the ACPI
>>> spec, if I read it right).
>>> So I was thinking about smth along the lines of:
>> Beata,
>>
>> Right, I see what you want to do.
>> Some comments inline.
>>
>> Would you like to make it a full patch so I can include it in the next
>> version? or some other way?
> What I have shared was just to ilustrate the idea, so if that's ok with you,
> you might carry on with that as well ?
>
> ---
> BR
> Beata
Sure, I will try to incorporate this and update.
...
More information about the linux-arm-kernel
mailing list