Re: [PATCH 11/17] sched_ext: Generalize the reject DSQ reenqueue path

Hello, Andrea.

On Sun, Aug 16, 2026 at 07:35:09PM +0200, Andrea Righi wrote:
> @@ -1807,6 +1806,9 @@ void scx_dispatch_dequeue(struct rq *rq, struct task_struct *p)
>  	}
>  	p->scx.dsq = NULL;
>
> +	if (dsq->id == SCX_DSQ_REJECT)
> +		p->scx.flags &= ~SCX_TASK_REENQ_REASON_MASK;

Two things bother me here. scx_dispatch_dequeue() is a DSQ unlink
primitive and managing the reason lifetime doesn't seem to belong in it.
And it leads to the following in scx_reenq_reject():

> 	list_for_each_entry_safe(p, n, &rq->scx.reject_dsq.list, scx.dsq_list.node) {
> +		u32 reason = p->scx.flags & SCX_TASK_REENQ_REASON_MASK;
...
>  		scx_dispatch_dequeue(rq, p);
> -
> -		if (WARN_ON_ONCE(p->scx.flags & SCX_TASK_REENQ_REASON_MASK))
> -			p->scx.flags &= ~SCX_TASK_REENQ_REASON_MASK;
> -		p->scx.flags |= SCX_TASK_REENQ_CAP;
> +		p->scx.flags |= reason;

where the drain clears the reason just to immediately put it back.

Can't we keep scx_dispatch_dequeue() oblivious of the reason and instead
clear it explicitly where its lifetime actually ends? ie. Clear directly
in dequeue_task_scx() after the DSQ removal and in the
SCX_DEQ_CORE_SCHED_EXEC path of set_next_task_scx(), and keep the
conditional helper for the reenqueue sites, maybe renamed to
scx_maybe_clear_reenq_reason() as clearing is conditional only there.
Then the drain doesn't need to save and restore anything.

Thanks.

--
tejun