Re: [PATCH] sched/fair: Fix wakeup_preempt_fair for not waking up task

[Furkan Çalışkan]

Hi Vincent,

On 4/29/26 19:41, Vincent Guittot wrote:
> The assumption that p is always enqueued and not delayed, is only true for
> wakeup. If p was moved while sched_delayed, pick_next_entity will dequeue
> it during the attach and the cfs might become empty.
> 
> Fixes: ac8e69e69363 ("sched/fair: Fix wakeup_preempt_fair() vs delayed dequeue")
> Signed-off-by: Vincent Guittot <vincent.guittot@xxxxxxxxxx>
> ---
> 
> I have triggered this while running my latency stress test on a new platform.
> 
>  kernel/sched/fair.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 728965851842..99fb524c4922 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -9147,7 +9147,7 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
>  	 * Because p is enqueued, nse being null can only mean that we
>  	 * dequeued a delayed task.
>  	 */
> -	if (!nse)
> +	if (!nse && (wake_flags & WF_TTWU))
>  		goto pick;
>  
>  	if (sched_feat(RUN_TO_PARITY))

When a sched_delayed task is migrated (which can only happen via MIGRATE_LOAD per can_migrate_task()), enqueuing it on the dest cpu will call wakeup_preempt_fair immediately, and if the dest cpu is not busy, pick_next_entity() will likely pick and dequeue it immediately. So a wasted enqueue+dequeue pair. Could we skip the enqueue when sched_delayed is set, and defer it to the actual wakeup path?

Thanks