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 17:31:43 +0200 Vincent Guittot <vincent.guittot@xxxxxxxxxx> wrote:

> > 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

Our system has a two-level scheduling hierarchy with 18 CPUs and 4 clusters:
0-1, 2-5, 6-9, 10-13, and 14-17. Each cluster is LLC (Last Level Cache), and
there are no finer levels of hierarchy.

I did overlook the detail regarding the SD_BALANCE_WAKE flag; our project did
not change the default state of the SD_BALANCE_WAKE flag, which is set to 0
Moreover, as far as I know, most embedded Linux projects have real-time
requirements and generally do not modify this SD_BALANCE_WAKE flag.

Given this situation, is it necessary to create a new branch for such a "_thin"
select_task_rq_fair() variant when enabling LB_PROMOTE?


> > 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

I can understand that the logic related to nr_idle_scan is very necessary when
there are a large number of CPUs. I realize that many x86 machines, even personal
PCs, have a considerable number of CPUs in their LLC.


--
Xin Zhao