Re: [RFC PATCH RESEND 04/10] sched/fair: Add LB_PROMOTE feature to enhance real-time performance of fair tasks

[Vincent Guittot]

On Thu, 10 Sept 2026 at 06:30, Xin Zhao <jackzxcui1989@xxxxxxx> wrote:
>
> Embedded platforms commonly use CONFIG_HZ_250, and testing has revealed
> that there are numerous instances of unreasonable CPU idle events on such
> platforms. Unreasonable CPU idle refers to situations where the CPU enters
> an idle state for a duration of time (t), while there are tasks that can
> run on the idle CPU and are not limited by cgroup constraints, yet these
> tasks remain unscheduled for a duration greater than (t), t > 2.5 ms.

Which looks reasonable with a 4ms tick

The ILB fixes this at next tick and we have a similar version for slow
path wake up

Also you might want to look at the newly idle load balance path

>
> Testing has shown that over 95% of these events last less than 4 ms, but
> there are still some instances of longer durations between 4-5ms, even
> occasionally between 5-10 ms. For a real-time system, scheduling delays
> greater than 4 ms can lead to performance spikes.

For a real-time system, use the real-time scheduler but you might want
to refer interactive systems

>
> Enabling this option can effectively reduce the occurrence of unreasonable
> CPU idle events on low HZ systems like CONFIG_HZ_250, and completely
> eliminate events exceeding 4 ms. Note that the feature only affects fair
> tasks.
>
> Note that enabling this feature will increase sys%, as it uses CPU time
> that would have been idle to expedite the scheduling of tasks. There will
> also be some CPU overhead involved in searching for suitable tasks.
>
> This feature has been split into several smaller patches, which will be
> elaborated on one by one later. Below are some test data:
>
> Test one compares the number of unreasonable CPU idle events and their
> distribution when this feature is enabled versus when it is not, under
> the same fillback scenario. The test duration was 60 seconds.
>
>       LB_PROMOTE(on/off) 2.5-3ms 3-4ms  4ms+
> index 0               on       0     0     0
> index 1              off       4    13     1
> index 2               on       0     0     0
> index 3              off       6     3     0
> index 4               on       0     0     0
> index 5              off       1     1     0
>
> Test two compares the performance of the system with and without the
> feature enabled, based on the same fillback scenario. Each test lasts for
> 25 minutes, and a total of 15 comparative tests were conducted. The
> results include a comparison of the maximum and median values of
> end-to-end latency and sys%.
>
> LB_PROMOTE(on/off)                    on        off
> end-to-end latency(max)              172        180
> end-to-end latency(median of avg)    166     167.68
> sys%(max)                           9.68       9.35
> sys%(median of avg)                 8.81       8.55
>
> Signed-off-by: Xin Zhao <jackzxcui1989@xxxxxxx>
> ---
>  kernel/sched/features.h | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
>
> diff --git a/kernel/sched/features.h b/kernel/sched/features.h
> index 8f0dee8fc475..4916a4b89ab3 100644
> --- a/kernel/sched/features.h
> +++ b/kernel/sched/features.h
> @@ -142,3 +142,27 @@ SCHED_FEAT(LATENCY_WARN, false)
>   */
>  SCHED_FEAT(NI_RANDOM, true)
>  SCHED_FEAT(NI_RATE, true)
> +
> +/*
> + * Embedded platforms commonly use CONFIG_HZ_250, and testing has revealed that
> + * there are numerous instances of unreasonable CPU idle events on such
> + * platforms. Unreasonable CPU idle refers to situations where the CPU enters
> + * an idle state for a duration of time (t), while there are tasks that can run
> + * on the idle CPU and are not limited by cgroup constraints, yet these tasks
> + * remain unscheduled for a duration greater than (t), t > 2.5 ms.
> + *
> + * Testing has shown that over 95% of these events last less than 4 ms, but
> + * there are still some instances of longer durations between 4-5ms, even
> + * occasionally between 5-10 ms. For a real-time system, scheduling delays
> + * greater than 4 ms can lead to performance spikes.
> + *
> + * Enabling this option can effectively reduce the occurrence of unreasonable
> + * CPU idle events on low HZ systems like CONFIG_HZ_250, and completely
> + * eliminate events exceeding 4 ms. Note that the feature only affects fair
> + * tasks.
> + *
> + * Note that enabling this feature will increase sys%, as it uses CPU time that
> + * would have been idle to expedite the scheduling of tasks. There will also be
> + * some CPU overhead involved in searching for suitable tasks.
> + */
> +SCHED_FEAT(LB_PROMOTE, false)
> --
> 2.34.1
>