Re: [PATCH sched_ext/for-7.2] sched_ext: check remote rq eligibility under task's rq lock

[Kuba Piecuch <jpiecuch@google.com>]

Hi Andrea,

Thank you for the review!

On Fri Jun 19, 2026 at 7:31 AM UTC, Andrea Righi wrote:
> Looks good to me, but we should also update the "Cross-CPU Task Migration" doc
> in kernel/sched/ext_internal.h to be consistent with this change (see below if
> it makes sense to you).
>
> With that:
>
> Reviewed-by: Andrea Righi <arighi@nvidia.com>
>
> Thanks,
> -Andrea
>
>  kernel/sched/ext_internal.h | 16 +++++++++-------
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/sched/ext_internal.h b/kernel/sched/ext_internal.h
> index b76633c52c96a..b63d80ae21157 100644
> --- a/kernel/sched/ext_internal.h
> +++ b/kernel/sched/ext_internal.h
> @@ -1471,18 +1471,20 @@ static const char *scx_enable_state_str[] = {
>   * The sched_ext core uses a "lock dancing" protocol coordinated by
>   * p->scx.holding_cpu. When moving a task to a different rq:
>   *
> - *   1. Verify task can be moved (CPU affinity, migration_disabled, etc.)
> - *   2. Set p->scx.holding_cpu to the current CPU
> - *   3. Set task state to %SCX_OPSS_NONE; dequeue waits while DISPATCHING
> + *   1. Set p->scx.holding_cpu to the current CPU
> + *   2. Set task state to %SCX_OPSS_NONE; dequeue waits while DISPATCHING
>   *      is set, so clearing DISPATCHING first prevents the circular wait
>   *      (safe to lock the rq we need)
> - *   4. Unlock the current CPU's rq
> - *   5. Lock src_rq (where the task currently lives)
> - *   6. Verify p->scx.holding_cpu == current CPU, if not, dequeue won the
> + *   3. Unlock the current CPU's rq
> + *   4. Lock src_rq (where the task currently lives)
> + *   5. Verify p->scx.holding_cpu == current CPU, if not, dequeue won the
>   *      race (dequeue clears holding_cpu to -1 when it takes the task), in
>   *      this case migration is aborted
> - *   7. If src_rq == dst_rq: clear holding_cpu and enqueue directly
> + *   6. If src_rq == dst_rq: clear holding_cpu and enqueue directly
>   *      into dst_rq's local DSQ (no lock swap needed)
> + *   7. Otherwise, verify under src_rq that the task can be moved to dst_rq
> + *      (CPU affinity, migration_disabled, etc.). If not, clear holding_cpu
> + *      and enqueue the task on the fallback DSQ on src_rq.
>   *   8. Otherwise: call move_remote_task_to_local_dsq(), which releases
>   *      src_rq, locks dst_rq, and performs the deactivate/activate
>   *      migration cycle (dst_rq is held on return)
>

Absolutely, will send a v2 shortly that includes the documentation change.

Thanks,
Kuba