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

[John Stultz]

On Fri, Jul 10, 2026 at 1:39 AM Andrea Righi <arighi@xxxxxxxxxx> 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... ).

thanks
-john