Re: SCX_ENQ_IMMED potentially leaving dispatched tasks lingering on local DSQs

[Tejun Heo <tj@kernel.org>]

Hello,

On Thu, Apr 23, 2026 at 09:48:11AM +0000, Kuba Piecuch wrote:
> I'm not sure if we should limit ourselves to just remote tasks.
> If we call wakeup_preempt(rq, p, flags) when adding @p to @rq's local DSQ
> regardless of whether @p/@rq is remote, then I think that should cover all
> cases and the patch above wouldn't be needed.

Sorry, I wasn't clear. I meant adding wakeup_preempt() in
move_remote_task_to_local_dsq() *in addition to* your nr_immed/RETRY_TASK
patch. That combination covers both cases:

- Local (your stepwise scenario): the task stays on the dispatching CPU, no
  migration happens, so there's no insertion-side hook to arm. Your nr_immed
  check in do_pick_task_scx() catches it on the RETRY_TASK path.

- Remote: move_remote_task_to_local_dsq() is SCX's analog of
  move_queued_task() and is missing the wakeup_preempt() call that
  move_queued_task() does after activate_task(). Once added,
  dst_rq->next_class is bumped to &ext_sched_class, and any subsequent
  higher-class wakeup on dst_rq routes through wakeup_preempt_scx() which
  already has the nr_immed reenqueue.

Adding wakeup_preempt() to local_dsq_post_enq() for every insertion would
work too, but I'd rather keep it in sync with how core sched handles
move_queued_task() and only add it where it's actually needed.

Thanks.

--
tejun