Re: [PATCH 08/18] sched: Introduce WF_ON_RQ wake flag

[K Prateek Nayak]

Hello Peter,

On 9/16/2026 2:49 PM, Peter Zijlstra wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 91f059a55695..9a583e3cc528 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -305,7 +305,7 @@ static inline int rb_sched_core_cmp(const void *key, const struct rb_node *node)
>  
>  void sched_core_enqueue(struct rq *rq, struct task_struct *p)
>  {
> -	if (p->se.sched_delayed)
> +	if (p->is_blocked)
>  		return;
>  
>  	rq->core->core_task_seq++;
> @@ -318,7 +318,7 @@ void sched_core_enqueue(struct rq *rq, struct task_struct *p)
>  
>  void sched_core_dequeue(struct rq *rq, struct task_struct *p, int flags)
>  {
> -	if (p->se.sched_delayed)
> +	if (p->is_blocked)
>  		return;
>  
>  	rq->core->core_task_seq++;

Although we don't support proxy with mis-matched cookie, this might
still be required down the line when we add support for it.

I can add it back then if that is a better option.

> @@ -1880,7 +1880,7 @@ static inline void uclamp_rq_inc(struct rq *rq, struct task_struct *p, int flags
>  		return;
>  
>  	/* Only inc the delayed task which being woken up. */
> -	if (p->se.sched_delayed && !(flags & ENQUEUE_DELAYED))
> +	if (p->is_blocked && !(flags & ENQUEUE_BLOCKED))
>  		return;
>  
>  	for_each_clamp_id(clamp_id)
> @@ -1907,7 +1907,7 @@ static inline void uclamp_rq_dec(struct rq *rq, struct task_struct *p)
>  	if (unlikely(!p->sched_class->uclamp_enabled))
>  		return;
>  
> -	if (p->se.sched_delayed)
> +	if (p->is_blocked)
>  		return;
>  
>  	for_each_clamp_id(clamp_id)
> @@ -2393,8 +2393,8 @@ unsigned long wait_task_inactive(struct task_struct *p, unsigned int match_state
>  		 * If task is sched_delayed, force dequeue it, to avoid always
>  		 * hitting the tick timeout in the queued case
>  		 */
> -		if (p->se.sched_delayed)
> -			dequeue_task(rq, p, DEQUEUE_SLEEP | DEQUEUE_DELAYED);
> +		if (p->is_blocked)
> +			dequeue_task(rq, p, DEQUEUE_SLEEP | DEQUEUE_BLOCKED);

For proxy donors, this will simply dequeue the task without
transitioning p->on_rq to 0.

If we want to break proxy at this point, maybe we want to bring
that __block_task() into dequeue task and do it for
DEQUEUE_BLOCKED?

>  		trace_sched_wait_task(p);
>  		running = task_on_cpu(rq, p);
>  		queued = task_on_rq_queued(p);
> @@ -3889,8 +3889,7 @@ static int ttwu_runnable(struct task_struct *p, int wake_flags)
>  
>  	update_rq_clock(rq);
>  	if (p->is_blocked) {
> -		if (p->se.sched_delayed)
> -			enqueue_task(rq, p, ENQUEUE_NOCLOCK | ENQUEUE_DELAYED);
> +		enqueue_task(rq, p, ENQUEUE_NOCLOCK | ENQUEUE_BLOCKED);

For proxy donors on rq that don't belong to fair, this will enqueue
an already enqueued task.

Although the sched call callbacks may be able to handle it,
psi_enqueue() will do double accounting since block_task() was
skipped for proxy donors.

>  		if (proxy_needs_return(rq, p))
>  			return 0;
>  	}

-- 
Thanks and Regards,
Prateek