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

[Tejun Heo <tj@kernel.org>]

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.

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.

Thanks.

--
tejun