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

[Andrea Righi <arighi@nvidia.com>]

On Fri, Jul 10, 2026 at 02:33:55PM -0700, John Stultz wrote:
> On Fri, Jul 10, 2026 at 1:39 AM Andrea Righi <arighi@nvidia.com> wrote:
> >
> > With proxy-exec, pick_next_task() can return a task with blocked_on set
> > (a proxy donor). put_prev_set_next_task() then calls set_next_task_scx()
> > on this "ghost" task even though the task only provides scheduling
> > context and never actually runs.
> >
> > Calling ops.running() for such a donor produces a spurious running
> > event. Simply suppressing ops.running() is not sufficient because the
> > following put_prev_task_scx() would still invoke ops.stopping(),
> > resulting in an unpaired stopping event.
> >
> > Introduce SCX_TASK_IS_RUNNING to track whether a task entered a real
> > running transition. Set and clear the flag independently of
> > ops.running() and ops.stopping(), as the callbacks are independently
> > optional. Invoke ops.running() only for non-blocked tasks and invoke
> > ops.stopping() only after a real running transition. This keeps the
> > callbacks paired for proxy donors while preserving stopping
> > notifications for schedulers which only implement ops.stopping().
> 
> It took me a while to understand this.
> 
> It seems you're wanting to distinguish normal task selection and
> execution (without proxy) from just task selection for proxy-donation
> (where it doesn't run).
> 
> I think what makes it confusing is that TASK_IS_RUNNING is not set for
> the case when the task is running (rq->curr) as a lock-owning proxy
> for a waiting donor.
> 
> Would it maybe make it easier to follow if the flag was
> TASK_BLOCKED_DONOR? And the logic was flipped a bit?
> 
> That might more clearly cover the case you intend here without extra
> edge cases that you'll have to explain (well, you're running but
> you're not the donor and running... ).

I agree that SCX_TASK_IS_RUNNING is confusing, because it doesn't describe
really well the rq->curr/physical execution.

What the flag records is whether a task entered the sched_ext running/stopping
state. With proxy-exec, the selected scheduling context (rq->donor) and the
physical execution context (rq->curr) can differ, which creates two relevant
cases:

 1. a blocked EXT donor goes through set_next_task_scx() even though its mutex
    owner executes instead. We must suppress ops.running() for the donor and
    remember that it did not enter the running state, so that a later
    ops.stopping() is also suppressed,

 2. an EXT mutex owner can execute as rq->curr for a non-EXT donor. The owner is
    not a blocked donor, but it did not go through set_next_task_scx(), so it
    must not receive ops.stopping() if it is subsequently dequeued.

So, I don't think changing the flag to SCX_TASK_BLOCKED_DONOR captures the
required state. SCX_TASK_IS_RUNNING handles both cases by recording whether the
task entered the sched_ext ops.running/stopping() state, independently of
whether either callback is implemented.

How about renaming it to SCX_TASK_IN_RUNNING_TRANSITION and explicitly
documenting that this is the sched_ext callback state, not physical rq->curr
execution? Something like:

  /* entered the SCX ops.running/stopping() state, not necessarily rq->curr */
  SCX_TASK_IN_RUNNING_TRANSITION = 1 << 6,

Any other ideas for a more clear name?

Thanks,
-Andrea