Re: [PATCH 09/15] sched_ext: Generalize the reject DSQ reenqueue path

On Mon, Aug 03, 2026 at 10:38:11AM -1000, Tejun Heo wrote:
> On Mon, Aug 03, 2026 at 10:35:16AM -1000, Tejun Heo wrote:
> > On Tue, Jul 28, 2026 at 05:43:27PM +0200, Andrea Righi wrote:
> > ...
> > > +static void scx_reenq_reject(struct rq *rq)
> > > +{
> > > +	LIST_HEAD(tasks);
> > > +	struct task_struct *p, *n;
> > > +
> > > +	lockdep_assert_rq_held(rq);
> > > +
> > > +	if (list_empty(&rq->scx.reject_dsq.list))
> > > +		return;
> > > +
> > > +	/*
> > > +	 * Move tasks to a private list so a task re-rejected by
> > > +	 * scx_do_enqueue_task() below isn't revisited this round.
> > > +	 */
> > > +	list_for_each_entry_safe(p, n, &rq->scx.reject_dsq.list, scx.dsq_list.node) {
> > > +		u32 reason = p->scx.reject_reason;
> > > +
> > > +		/* migration_pending tasks should have bypassed to local DSQ */
> > > +		if (WARN_ON_ONCE(p->migration_pending))
> > > +			continue;
> > > +		if (WARN_ON_ONCE(!reason))
> > > +			continue;
> > > +
> > > +		scx_dispatch_dequeue(rq, p);
> > > +		p->scx.reject_reason = SCX_TASK_REENQ_NONE;
> > > +
> > > +		if (WARN_ON_ONCE(p->scx.flags & SCX_TASK_REENQ_REASON_MASK))
> > > +			p->scx.flags &= ~SCX_TASK_REENQ_REASON_MASK;
> > > +		p->scx.flags |= reason;
> > 
> > Can you separate out code movement and actual changes into separate patches?
> > Even for relatively simple changes, combining move and changes adds
> > significant unnecessary review friction.
> 
> I wonder whether the reason can be carried in p->scx.flags from the
> rejection site instead of bouncing through p->scx.reject_reason.

Ack, I think it's possible. I'll split the patches and set the rejection reason
directly in p->scx.flags.

Thanks,
-Andrea