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

[Vincent Guittot]

On Sat, 12 Sept 2026 at 06:08, Xin Zhao <jackzxcui1989@xxxxxxx> wrote:
>
> On Fri, 11 Sep 2026 14:27:04 +0200 Vincent Guittot <vincent.guittot@xxxxxxxxxx> wrote:
>
> > > 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 ?
>
> Due to fair scheduling, especially in a 250Hz system, we often experience significant
> scheduling delays. Therefore, we have already converted many critical tasks to real-time
> in our projecct. Currently, there are already a considerable number of real-time tasks
> running on our system. The following is the data on our system:

Ok, But mentioning Real-time for fair scheduling is misleading because
fair is not  a real-time scheduler. We often speak about interactive
systems in this case because we can't put any real time limit on fair
only some best effort.

>
> CPU ID | Total Tasks | Real-time Tasks
> ------------------------------------------
> 0 | 369          | 197
> 1 | 293          | 132
> 2 | 166          | 53
> 3 | 103          | 27
> 4 | 89          | 26
> 5 | 63          | 29
> 6 | 173          | 61
> 7 | 215          | 39
> 8 | 181          | 53
> 9 | 77          | 21
> 10 | 90          | 47
> 11 | 119          | 63
> 12 | 55          | 23
> 13 | 50          | 27
> 14 | 85          | 33
> 15 | 143          | 50
> 16 | 156          | 40
> 17 | 159          | 44
>
>
> The RT tasks/total tasks percent is already very high. It is no longer feasible to expand
> the scope of real-time tasks, including tasks like kworker, ksoftirqd, and kswap, which
> are not suitable for real-time scheduling, right? In particular, within kworker and
> ksoftirqd, there are still many scenarios where insufficient scheduling timeliness leads
> to increased processing delays in the entire pipeline.

Regarding timeliness, you shoudl have a look at eevdf slice as a way
to order (up to a point) your task scheduling

>
> The LB_PROM feature and its associated series of patches are specifically designed to
> address this issue. One of the most significant core changes is patch 10; you may want to
> take a look at it first. The remaining patches (patch 5, this patch, patch7, patch 8, and
> patch 9) all contribute to improving fair scheduling delays.
>
>
> > > 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.
>
> I took a closer look at the implementation of sched_balance_find_dst_cpu and believe that
> this function already meets the requirements. I'm wondering if it would be possible to add
> the SD_BALANCE_WAKE flag to the scheduling domains (sd) of each CPU when the LB_PROMOTE
> feature is enabled, and then revert it back to 0 after the LB_PROMOTE feature is disabled.
> Would that be feasible?

I don't like how you use sched_feature to enable the "LB_PROMOTE".
sched_feature are there to ease testing the impact of a feature of the
some results not to enable/disable it dynamiccally.

>

>
> --
> Xin Zhao
>