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

[Kuba Piecuch <jpiecuch@google.com>]

Hi Tejun,

On Fri Apr 24, 2026 at 5:17 PM UTC, Tejun Heo wrote:
> Hello, Kuba.
>
> On Fri, Apr 24, 2026 at 09:22:44AM +0000, Kuba Piecuch wrote:
>> @@ -1408,11 +1407,19 @@ static void local_dsq_post_enq(struct scx_sched *sch, struct scx_dispatch_q *dsq
>>  	if ((enq_flags & SCX_ENQ_PREEMPT) && p != rq->curr &&
>>  	    rq->curr->sched_class == &ext_sched_class) {
>>  		rq->curr->scx.slice = 0;
>> -		preempt = true;
>> +		resched_curr(rq);
>>  	}
>>  
>> -	if (preempt || sched_class_above(&ext_sched_class, rq->curr->sched_class))
>> -		resched_curr(rq);
>
> 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:

	void wakeup_preempt(struct rq *rq, struct task_struct *p, int flags)
	{
		[...]

		if (p->sched_class == rq->next_class) {
			rq->next_class->wakeup_preempt(rq, p, flags);

		} else if (sched_class_above(p->sched_class, rq->next_class)) {
			rq->next_class->wakeup_preempt(rq, p, flags);
		=====>	resched_curr(rq);  <=====
			rq->next_class = p->sched_class;
		}

		[...]
	}

>
>> +	/*
>> +	 * 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).
	 */

Thanks,
Kuba