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

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.

Thanks.

-- 
tejun