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

[Xin Zhao]

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:

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.

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?


--
Xin Zhao