Re: [PATCH RFC v2] sched/proxy: Defer donor commit until after proxy resolution

[John Stultz]

On Sun, Jul 12, 2026 at 11:22 PM Xukai Wang <kingxukai@xxxxxxxxxxxx> wrote:
>
> pick_next_task() currently commits the selected task into the scheduling
> class state before proxy execution has resolved whether that task should
> really become the committed donor.
>
> With proxy execution enabled, the task returned by pick_next_task() may
> be blocked. __schedule() then calls find_proxy_task() to resolve the
> proxy chain. If find_proxy_task() returns NULL, __schedule() retries
> through pick_again, but the picked donor has already gone through
> put_prev_set_next_task(). In that case the class current state was
> speculatively switched to a donor which is not the final scheduling
> decision.
>
> Make pick_next_task() return only the selected candidate task. Move the
> put_prev_set_next_task() call into __schedule(), next to rq_set_donor(),
> so the scheduling class commit happens after proxy-chain resolution.

Hey Xukai!
  Thanks for sending this out, and my apologies for being a little
slow to respond.

It might help if your commit message focused in to explain a bit more
about *why* these changes are useful.

ie: Why is the call to set_next_task on the donor problematic if we
pick a different task to run?

Is this just trying to optimize out the potentially repeated
put_prev/set_next calls needed if we have to pick_again repeatedly? Or
are there other benefits?

What is the impact of this change? Is it measurable?

These would be good things to answer at the top of the commit message.

thanks
-john