Re: [PATCH 0/6 v8] sched/fair: Add push task mechanism and handle more EAS cases

[Qais Yousef <qyousef@layalina.io>]

On 03/10/26 11:27, Pierre Gondois wrote:

> If we have 2 little CPUs (CPU0/CPU1) with 4 tasks:
> - TaskA: Nice=10 (i.e. weight=110)
> - Task[B,C,D]: Nice=15 (i.e. weight=36)
> 
> Then using nr_running would yield a placement as with 2 tasks
> on each CPU:
> - CPU0: TaskA + TaskB
>   Total weight = 110 + 36 = 146
> - CPU1: TaskC + TaskD
>   Total weight = 36 + 36 = 52
> With such placement:
> - TaskA and TaskB are receiving less throughput
> - TaskC and TaskD are receiving more throughput
> than what they would if the placement was balanced.
> 
> This is not compliant with the scheduler Nice interface.

This is over thinking it. On 2 core SMP system, no uclamp and no EAS. 4 always
busy tasks with different nice values will still be placed based on load and
neither wake up path nor load balancer has notion of throughput based on nice
to manage task placement.

Generally with EEVDF managing the slice size is better than nice value and with
the QoS framework we are proposing I think nice value is better locked down to
0. But we shall see.

More over the idea is to enable wake up path to be multi-modal and coherent
with lb decision (via push lb). So fixing all these problems is possible in the
future, fingers crossed without much added complexity. But again, we shall see.