Re: [PATCH v5 5/6] sched/fair: Allow load balancing between CPUs of identical capacity

[Vincent Guittot]

On Fri, 26 Jun 2026 at 02:02, Ricardo Neri
<ricardo.neri-calderon@xxxxxxxxxxxxxxx> wrote:
>
> On Tue, Jun 23, 2026 at 10:25:14PM -0700, Ricardo Neri wrote:
> > On Tue, Jun 23, 2026 at 08:45:23AM +0100, Christian Loehle wrote:
> > > On 6/23/26 08:20, Vincent Guittot wrote:
> > > > On Tue, 23 Jun 2026 at 01:55, Ricardo Neri
> > > > <ricardo.neri-calderon@xxxxxxxxxxxxxxx> wrote:
> > > >>
> > > >> sched_balance_find_src_rq() avoids selecting a runqueue with a single
> > > >> running task as busiest if doing so results in migrating the task to a
> > > >> CPU with less than ~5% of extra capacity. It also unintentionally
> > > >> prevents migrations between CPUs of identical capacity.
> > > >>
> > > >> When CONFIG_SCHED_CLUSTER is enabled, load should be balanced across
> > > >> clusters of CPUs with the same capacity. Allowing migration between CPUs
> > > >> of identical capacity is necessary to meet this goal.
> > > >>
> > > >> Use arch_scale_cpu_capacity() to reflect architectural capacity, excluding
> > > >
> > > > capacity_of() reflects not only RT and irq pressure but also thermal
> > > > pressure or system frequency capping.
> > > > If dst cluster is under thermal mitigation but the source cluster is
> > > > not, we probably shouldn't spread tasks across both clusters.
> > > > Have you considered using get_actual_cpu_capacity() instead of
> > > > arch_scale_cpu_capacity() ?
> > >
> > > Replacing arch_scale_cpu_capacity() with get_actual_cpu_capacity()
> > > would make the == comparison below very unlikely to be true FWIW.
> >
> > Yes, this is what I thought too. I did not try with get_actual_cpu_capacity(),
> > though. Perhaps on Intel processors it would work since rq->avg_hw.load_avg
> > is not used, IIUC. I am not sure about cpufreq_pressure. I need to check.
> >
> > Still, it may work for Intel processors but not for ARM ones.
> >
> > > I think it's fine like that, I will prepare a follow-up anyway to make
> > > it work for our "almost equal capacity" cluster systems and then also
> > > consider switching to get_actual_cpu_capacity() since we include a margin
> > > anyway.
> >
> > Great!
>
> I confirmed that does not use rq->avg_hw.load_avg nor cpufreq_pressure.

I'm not surprised that intel don't use rq->avg_hw.load_avg  but I'm
pretty sure that you use cpufreq_pressure, because any call to
freq_qos_add_request(..., FREQ_QOS_MAX), like scaling_max_freq, will
update cpufreq_pressure.

If one cluster has its max freq capped, you will spread tasks between
the uncapped and the capped clusters which no longer have the same
compute capacity.

> Hence, get_actual_cpu_capacity() worked for me on Intel hybrid processors,
> but it would not on other architectures.
>
> So perhaps we can stick with arch_scale_cpu_capacity() for now? The series
> from Christian will add a margin, making the use of get_actual_cpu_capacity()
> feasible.