Re: [PATCH 09/17] sched_ext: Fix ops.running/stopping() pairing for proxy-exec donors

[Andrea Righi <arighi@nvidia.com>]

On Sun, Aug 16, 2026 at 12:10:16PM -1000, Tejun Heo wrote:
> Hello,
> 
> On Sun, Aug 16, 2026 at 07:35:07PM +0200, Andrea Righi wrote:
> > +static void set_next_task_scx(struct rq *rq, struct task_struct *p, bool first)
> > +{
> >  	if (p->scx.flags & SCX_TASK_QUEUED) {
> >  		/*
> >  		 * Core-sched might decide to execute @p before it is
> > @@ -3024,9 +3037,14 @@ static void set_next_task_scx(struct rq *rq, struct task_struct *p, bool first)
> >  
> >  	p->se.exec_start = rq_clock_task(rq);
> >  
> > -	/* see dequeue_task_scx() on why we skip when !QUEUED */
> > -	if (SCX_HAS_OP(sch, running) && (p->scx.flags & SCX_TASK_QUEUED))
> > -		SCX_CALL_OP_TASK(sch, running, rq, p);
> > +	/*
> > +	 * See dequeue_task_scx() for why we skip when !QUEUED. On a normal
> > +	 * scheduling transition, defer starting a blocked donor's session until
> > +	 * proxy resolution succeeds. A restore follows an already resolved
> > +	 * scheduling context and can start the session immediately.
> > +	 */
> > +	if ((p->scx.flags & SCX_TASK_QUEUED) && (!p->is_blocked || !first))
> > +		scx_start_task_running(rq, p);
> 
> nit: can we do !(p->is_blocked && first) instead? I think that matches
> what's being expressed better.
> 
> Also, can you expand the comment? I find it a bit difficult to follow. So,
> when we're actually switching to a donor, we skip running transition because
> proxy resolution might give us nothing or it may have to run on a differnet
> CPU and so on, so we do running transition after proxy resolution is done.
> For SAVE/RESTORE, this doesn't apply as they're always matched regardless of
> donor state. Is that the right reading?

Yes, that's the intended behavior. When @first is set, a blocked task is only a
provisional donor: proxy-exec may fail or migrate the donor to another CPU, so
ops.running() is deferred until resolution succeeds. When !@first, this is the
restore side of a SAVE/RESTORE cycle, the matching dequeue already issued
ops.stopping(), so ops.running() must be restarted regardless of the donor
state. I'll change the condition and expand the comment.

> 
> >  	clr_task_runnable(p, true);
> >  
> > @@ -3072,6 +3090,13 @@ static void set_next_task_scx(struct rq *rq, struct task_struct *p, bool first)
> >  
> >  void scx_proxy_donor_start(struct rq *rq)
> >  {
> > +	struct task_struct *donor = rq->donor;
> > +
> > +	lockdep_assert_rq_held(rq);
> > +
> > +	if (donor->sched_class == &ext_sched_class &&
> > +	    (donor->scx.flags & SCX_TASK_QUEUED))
> 
> another nit: no need for line break.

Ack.

Thanks,
-Andrea

> 
> > +		scx_start_task_running(rq, donor);
> >  }
> 
> Thanks.
> 
> -- 
> tejun