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

[K Prateek Nayak <kprateek.nayak@amd.com>]

On 9/16/2026 4:00 PM, Peter Zijlstra wrote:
> On Wed, Sep 16, 2026 at 03:57:54PM +0530, K Prateek Nayak wrote:
> 
>>> @@ -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.
> 
> For both the idea would be that {EN,DE}QUEUE_BLOCKED would be ignored
> when inappropriate.
> 
> Eg. fair will no-op when !sched_delayed.
> 
> I did mention none of the other classes behave properly in this regard,
> although the note was perhaps a little cryptic.

My bad! But what do you think about having a bitmap of allowed flags
that lives in sched_class->flags and is checked at enqueue / dequeue?

Only the lower nibble is set conditionally for matching flags and the
upper ones are set unconditionally. Only user would be fair for
DEQUEUE_BLOCKED / ENQUEUE_BLOCKED but is kinda extensible if more
class specific flags emerge.

-- 
Thanks and Regards,
Prateek