Re: [PATCH v3] sched_ext: include SCX_OPS_TRACK_MIGRATION

[Henry Huang]

On Mon, 23 Jun 2025 07:59:54 -1000, Tejun Heo wrote:
> It's rather odd to invoke runnable/quiescent on these transitions as the
> runnable state isn't actually changing and the events end up triggering for
> all the migration operations that SCX does internally.
>
> In the head message (BTW, if it's just a single patch, it'd be better to
> include all the context in the patch description), you said that this is
> needed to udpate percpu data structures when tasks migrate. Wouldn't you be
> able to do that by tracking whether the current CPU is different from the
> previous one from ops.running()?

We will traverse the per-CPU map information in ops.select_cpu() to select
the appropriate CPU. To reduce the competition for the rq spinlock, tasks are
likely to run on the CPU selected by ops.select_cpu().

However, I can think of two scenarios where passive migration may occur:
1. set_task_allowed_cpus
2. cpu_stop
There may also be some passive migration scenarios that we haven't thought of.
This could lead to incorrect information in the per-CPU map. Therefore,
we hope to track enqueue_task_scx and dequeue_task_scx to ensure that the
information in the per-CPU map is accurate.

-- 
Henry