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

[Xin Zhao]

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.

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.


--
Xin Zhao