Re: [PATCH v3 1/2] arch_topology: seed capacity_freq_ref with highest available frequency

[Ananthu C V <ananthu.cv@oss.qualcomm.com>]

Hi Zhongiu and Dietmar,

On Tue, Oct 13, 2026 at 07:28:31PM +0800, Zhongqiu Han wrote:
> On 10/13/2026 2:45 AM, Dietmar Eggemann wrote:
> > On 11.10.26 16:16, Zhongqiu Han wrote:
> > > On 9/29/2026 7:38 PM, Ananthu C V wrote:
> > 
> > [...]
> > 
> > > Besides, could you comment patch v2 Dietmar's comments? It seems that
> > > patch 1/2 exposes a pre-existing ordering issue. On DT systems,
> > > cpu_scale is normalized only from the CPUFREQ_CREATE_POLICY notification
> > > of the last policy, so the cpufreq pressure of every other policy is
> > > computed in cpufreq_init_policy() from the raw, not yet normalized,
> > > capacity, and stays cached until the next cpufreq_set_policy() for that
> > > policy. So far this was harmless because capacity_freq_ref == policy-
> > > > max at boot, so the pressure was 0 regardless of the capacity. With
> > > 1/2, capacity_freq_ref covers the boost frequencies while boost is
> > > disabled at boot, so policy->max < capacity_freq_ref becomes the common
> > > case and the stale value becomes visible (102 vs 79 on Juno R0, as
> > > reported by Dietmar). Perhaps the limits of all policies could be
> > > refreshed once from parsing_done_workfn(), after the capacities have
> > > been normalized?
> > > 
> > > --- a/drivers/base/arch_topology.c
> > > +++ b/drivers/base/arch_topology.c
> > > @@ -454,9 +454,27 @@ core_initcall(register_cpufreq_notifier);
> > > 
> > >   static void parsing_done_workfn(struct work_struct *work)
> > >   {
> > > +    int cpu;
> > > +
> > >       cpufreq_unregister_notifier(&init_cpu_capacity_notifier,
> > >                        CPUFREQ_POLICY_NOTIFIER);
> > >       free_cpumask_var(cpus_to_visit);
> > > +
> > > +    /*
> > > +     * The cpufreq pressure of all policies but the last one has been
> > > +     * computed before topology_normalize_cpu_scale(), so refresh it now
> > > +     * that cpu_scale is final.
> > > +     */
> > > +    for_each_possible_cpu(cpu) {
> > > +        struct cpufreq_policy *policy __free(put_cpufreq_policy) =
> > > +            cpufreq_cpu_get(cpu);
> > > +
> > > +        if (!policy || cpu != policy->cpu)
> > > +            continue;
> > > +
> > > +        guard(cpufreq_policy_write)(policy);
> > > +        refresh_frequency_limits(policy);
> > > +    }
> > Yes, IMHO, something like this is needed.
> 
> Thanks for the test verification and the discussion.

Thanks to both of you for the discussion and suggestions. I am noticing similar
pressure update related patterns on glymur as well, so the discovery is very
valid, thanks for that. I will take in your suggestions and include patches to
fix the pressure scenario in the next revision.

> --
> Thx and BRs,
> Zhongqiu Han

Best,
Ananthu