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

From: Tejun Heo

Date: Sun Aug 16 2026 - 18:45:58 EST


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