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

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.

Thanks.

-- 
tejun