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

[Andrea Righi]

Hi Tejun,

On Sun, Aug 16, 2026 at 12:45:50PM -1000, Tejun Heo wrote:
> 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.

Yes, that makes sense. The reason lifetime belongs to the reenqueue transaction,
ratehr than the generic DSQ unlink primitive. I'll keep scx_dispatch_dequeue()
oblivious to it, clear it explicitly from dequeue_task_scx() and the core-sched
execution path, and rename the conditional reenqueue helper.

Thanks for lookinga at this series!
-Andrea