Re: [RFC PATCH RESEND 05/10] sched/fair: Introduce select_task_rq_fair_thin() to select rq when LB_PROMOTE

[Vincent Guittot]

On Thu, 10 Sept 2026 at 16:39, Xin Zhao <jackzxcui1989@xxxxxxx> wrote:
>
> On Thu, 10 Sep 2026 10:19:13 +0200 Vincent Guittot <vincent.guittot@xxxxxxxxxx> wrote:
>
> > > +/*
> > > + * A streamlined version of select_task_rq_fair().
> > > + * It runs faster than select_task_rq_fair, especially when there are not
> > > + * many CPUs. It will prioritize selecting an idle CPU in the following order:
> > > + * 1. prev_cpu
> > > + * 2. recent_used_cpu
> > > + * 3. cpu belongs to intersection of sd_llc and cpus_ptr
> > > + * 4. cpu belongs to cpus_ptr but not belongs to sd_llc
> > > + * If there is no idle CPU in cpus_ptr, it will select prev_cpu.
> > > + */
> > > +static int select_task_rq_fair_thin(struct task_struct *p, int prev_cpu, int wake_flags)
> >
> > We don't want yet another select idle cpu function.
> > The only reason select_idle_sibling() would not select an idle cpu in
> > your llc is nr_idle_scan which will abort the loop before checking all
> > CPUs. You should look at why nr_idle_scan doesn't keep all CPUs in
> > your small size use cases
>
> Adding such a function to the mainline code is indeed not a good idea. What I
> actually want is to prioritize selecting idle CPUs within the LLC first, and
> then select idle CPUs outside the LLC. However, once the fast path taken, if
> I’m not mistaken, it only selects CPUs within the LLC, which is not very
> friendly for machines on embedded platforms, as it becomes difficult to bind
> tasks without crossing LLC boundaries when the number of CPUs is small.

Ok, I didn't notice that you were looking at all CPUs, not only the
last LLC. Do you have more details about your cpu topology to share
with us?

we have sched_balance_find_dst_cpu() which looks wider but needs
SD_BALANCE_WAKE to be set in your sched domain topology

>
> I’m considering I can modify it as follows:
> want_affine = !wake_wide(p) && cpumask_test_cpu(cpu, p->cpus_ptr) && !sched_feat(LB_PROMOTE);
> to force the slow path for core selection whenLB_PROMOTE` is enabled.
>
> BTW,
> Regarding nr_idle_scan, I have derived some data and the analysis is as follows:
>
> If nr_idle_scan is 2, then: y must be at least 512, tmp must be <=512, and tmp
> must be <= 512 * 10000 * 1024. This leads to tmp <= sqrt(512 * 10000 * 1024 / 117 / 117),
> which is the square of 382,999.488, resulting in approximately 618.8695 after
> taking the square root.
>
> Multiplying this by 4 gives us 2476, so if the estimated utilization of CFS
> tasks exceeds 60.54%,nr_idle_scan` must be less than 3 and becomes 2, which
> may result in missing idle CPUs within the LLC.

nr_idle_scan has been design with large llc in mind where scanning
hundreds of CPU is significant but when you have only few cores, we
could be more relax in the number of cpu to scan

>
>
> --
> Xin Zhao
>