Re: [PATCH sched_ext/for-7.1-fixes] sched_ext: Call wakeup_preempt() in local_dsq_post_enq()

[Tejun Heo <tj@kernel.org>]

On Mon, Apr 27, 2026 at 02:14:33PM +0000, Kuba Piecuch wrote:
> > Hmm... I don't quite understand this part of the change. sched_class_above()
> > got separated out into its own case but why is it dropping resched_curr() on
> > SCX_ENQ_PREEMPT?
> 
> In the SCX_ENQ_PREEMPT case we call resched_curr() where we previously set
> preempt = true.
> 
> In the sched_class_above() case, wakeup_preempt() will call resched_curr()
> for us:

I see. It'd be helpful to note that in desc.

> >> +	/*
> >> +	 * If @rq->next_class is currently idle, we need to bump it
> >> +	 * to &ext_sched_class using wakeup_preempt(). Otherwise, if we drop
> >> +	 * the rq lock later in the pick and an RT task wakes up on @rq,
> >> +	 * wakeup_preempt_idle() will be called during RT task wakeup and
> >> +	 * SCX won't have an opportunity to re-enqueue IMMED tasks from @rq's
> >> +	 * local DSQ.
> >
> > As this was really subtle, I think it warrants documenting all cases here.
> 
> Yeah, I was trying to keep it concise. How about something like this:
> 
> 	/*
> 	 * Note that @rq's lock may be dropped between this enqueue and @p
> 	 * actually getting on CPU. This gives higher-class tasks (e.g. RT)
> 	 * an opportunity to wake up on @rq and prevent @p from running.
> 	 * Here are some concrete examples:
> 	 *
> 	 * Example 1:
>          *
> 	 * We dispatch two tasks from a single ops.dispatch():
> 	 * - First, a local task to this CPU's local DSQ;
> 	 * - Second, a local/remote task to a remote CPU's local DSQ.
> 	 * We must drop the local rq lock in order to finish the second
> 	 * dispatch. In that time, an RT task can wake up on the local rq.
> 	 *
> 	 * Example 2:
> 	 *
> 	 * We dispatch a local/remote task to a remote CPU's local DSQ.
> 	 * We must drop the remote rq lock before the dispatched task can run,
> 	 * which gives an RT task an opportunity to wake up on the remote rq.
> 	 *
> 	 * Both examples work the same if we replace dispatching with moving
> 	 * the tasks from a user-created DSQ.
> 	 *
> 	 * We must detect these wakeups so that we can re-enqueue IMMED tasks
> 	 * from @rq's local DSQ. scx_wakeup_preempt() serves exactly this
> 	 * purpose, but for it to be invoked, we must ensure that we bump
> 	 * @rq->next_class to &ext_sched_class if it's currently idle.
> 	 *
> 	 * wakeup_preempt() does the bumping, and since we only invoke it if
> 	 * @rq->next_class is below &ext_sched_class, it will also
> 	 * resched_curr(rq).
> 	 */

Looks good to me.

Thanks.

-- 
tejun