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

[Ricardo Neri]

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!