Re: [PATCH v26 00/10] Simple Donor Migration for Proxy Execution

[K Prateek Nayak]

Hello Peter,

On 3/27/2026 5:18 PM, Peter Zijlstra wrote:
> I tried to have a quick look, but I find it *very* hard to make sense of
> the differences.

Couple of concerns I had with the current approach is:

1. Why can't we simply do block_task() + wake_up_process() for return
   migration?

2. Why does proxy_needs_return() (this comes later in John's tree but I
   moved it up ahead)  need the proxy_task_runnable_but_waking() override
   of the ttwu_state_mach() machinery?
   (https://github.com/johnstultz-work/linux-dev/commit/28ad4d3fa847b90713ca18a623d1ee7f73b648d9)

3. How can proxy_deactivate() see a TASK_RUNNING for blocked donor?


So I went back after my discussion with John at LPC to see if the 
ttwu_state_match() stuff can be left alone and I sent out that
incomprehensible diff on v24.

Then I put a tree where my mouth is to give better rationale behind
each small hunk that was mostly in my head until then. Voila, another
(slightly less) incomprehensible set of bite sized changes :-)

> 
> Anyway, this:
> 
>>   fd60c48f7b71 sched: Avoid donor->sched_class->yield_task() null traversal
> 
> That seems *very* dodgy indeed. Exposing idle as the donor seems ... wrong?

That should get fixed by
https://github.com/kudureranganath/linux/commit/82a29c2ecd4b5f8eb082bb6a4a647aa16a2850be

John has mentioned hitting some warnings a while back from that
https://lore.kernel.org/lkml/f5bc87a7-390f-4e68-95b0-10cab2b92caf@xxxxxxx/

Since v26 does proxy_resched_idle() before doing
proxy_release_rq_lock() in proxy_force_return(), that shouldn't be a
problem.

Speaking of that commit, I would like you or Juri to confirm if it is
okay to set a throttled deadline task as rq->donor for a while until it
hits resched.

> 
> 
> Anyway, you seem to want to drive the return migration from the regular
> wakeup path and I don't mind doing that, provided it isn't horrible. But
> we can do this on top of these patches, right?
> 
> That is, I'm thinking of taking these patches, they're in reasonable
> shape, and John deserves a little progress :-)
> 
> I did find myself liking the below a little better, but I'll just sneak
> that in.

So John originally had that and then I saw Dan's comment in
cleanup.h that reads:

  Lastly, given that the benefit of cleanup helpers is removal of
  "goto", and that the "goto" statement can jump between scopes, the
  expectation is that usage of "goto" and cleanup helpers is never
  mixed in the same function. I.e. for a given routine, convert all
  resources that need a "goto" cleanup to scope-based cleanup, or
  convert none of them.

which can either be interpreted as "Don't do it unless you know what
you are doing" or "There is at least one compiler that will get a
goto + cleanup guard wrong" and to err on side of caution, I
suggested we do break + enums.

If there are no concerns, then the suggested diff is indeed much
better.

-- 
Thanks and Regards,
Prateek