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 17:57, Xin Zhao <jackzxcui1989@xxxxxxx> wrote:
>
> 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

But if you have real-time requirements, why don't you use the
real-time scheduler ?

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

At now, I don't see a need for a new branch nor a LB_PROMOTE. You
failed to describe your problem and came up with thos
platform-specific solution instead of fixing current code. Putting it
behind LB_PROMOTE, doesn't make it better.


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