Re: [PATCH 09/17] sched_ext: Fix ops.running/stopping() pairing for proxy-exec donors
From: Tejun Heo
Date: Sun Aug 16 2026 - 18:10:21 EST
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?
> 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.
> + scx_start_task_running(rq, donor);
> }
Thanks.
--
tejun