Re: [PATCH v2 sched_ext/for-7.2-fixes] sched_ext: Preserve rq tracking across local DSQ dispatch

[Andrea Righi <arighi@nvidia.com>]

Hi Tejun,

On Tue, Jul 07, 2026 at 12:36:34PM -1000, Tejun Heo wrote:
> Hello, Andrea.
> 
> Instead of clearing and restoring the tracking at the function boundaries,
> can you wrap the lock switch itself so scx_locked_rq() follows it? Something
> like:
> 
> 	static void switch_rq_lock(struct rq *from, struct rq *to)
> 	{
> 		bool tracked = scx_locked_rq() == from;
> 
> 		if (tracked)
> 			update_locked_rq(NULL);
> 		raw_spin_rq_unlock(from);
> 		raw_spin_rq_lock(to);
> 		if (tracked)
> 			update_locked_rq(to);
> 	}
> 
> Then use it at the unlock/lock pairs in dispatch_to_local_dsq(),
> move_remote_task_to_local_dsq(), and scx_dsq_move() (the in_balance ones;
> the !in_balance fresh lock stays). That keeps scx_locked_rq() naming the
> actually-held rq the whole time instead of going NULL across the dance, and
> drops the tracked_rq bookkeeping, the WARN_ON_ONCE()s, and the
> in_balance-vs-scx_locked_rq() coupling.

Makes sense, I'll send a v3 shortly with these changes for for-7.2-fixes.

> 
> The == from guard makes it a no-op for the consume path (there it's this_rq,
> not the rq being released), so that stays as-is for now - it's harmless
> today because the deactivate runs under the migration guards. Would be nice
> to bring consume under the same helper on for-7.3 so the tracking is
> faithful everywhere.

Ack, I'll follow up with a separate for-7.3 patch to keep the rq tracking
accurate in the consume path as well.

Thanks,
-Andrea