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

[K Prateek Nayak]

Hello John,

On 3/25/2026 12:43 AM, John Stultz wrote:
> I really want to share my appreciation for feedback provided by
> Peter, K Prateek and Juri on the last revision! 

And we really appreciate you working on this! (Cannot state this
enough)

> There’s also been some further improvements In the full Proxy
> Execution series:
> * Tweaks to proxy_needs_return() suggested by K Prateek

To answer your question on v25, I finally seem to have
ttwu_state_match() happy with the pieces in:
https://github.com/kudureranganath/linux/commits/kudure/sched/proxy/ttwu_state_match/

The base rationale is still the same from
https://lore.kernel.org/lkml/eccf9bb5-8455-48e5-aa35-4878c25f6822@xxxxxxx/

tl;dr

Use rq_lock() to serialize clearing of "p->blocked_on". All the other
transition change "p->blocked_on" non-NULL values. Exploit this to use
ttwu_state_match() + ttwu_runnable() in our favor when waking up blocked
donors and handling their return migration.


These are the commits of interest on the tree with a brief explanation:

I added back proxy_reset_donor() for the sake of testing now that a
bunch of other bits are addressed in v26. I've mostly been testing at
the below commit (this time with LOCKDEP enabled):

    82a29c2ecd4b sched/core: Reset the donor to current task when donor is woken
    ...
    5dc4507b1f04 [ANNOTATION] === proxy donor/blocked-waiter migration before this point  ===

Above range which has you as the author has not been touched - same as
what you have on your proxy-exec-v26-7.0-rc5 branch.

I did not tackle sleeping owner bits yet because there are too many
locks, lists, synchronization nuances that I still need to wrap my
head around. That said ...

The below is making ttwu_state_match() sufficient enough to handle
the return migration which allows for using wake_up_process(). The
patches are small and the major ones should have enough rationale
in the comments and the commit message to justify the changes.

  0b3810f43c66 sched/core: Simplify proxy_force_return()
  609c41b77eaf sched/core: Remove proxy_task_runnable_but_waking()
  157721338332 sched/core: Prepare proxy_deactivate() to comply with ttwu state machinery
  abefa0729920 sched/core: Allow callers of try_to_block_task() to handle "blocked_on" relation


Only change to below was conflict resolution as a result of some
re-arrangement.

  787b078b588f sched: Handle blocked-waiter migration (and return migration)


These are few changes to proxy_needs_return() exploiting the idea
of "p->blocked_on" being only cleared under rq_lock:

  84a2b581dfe8 sched/core: Remove "p->wake_cpu" constraint in proxy_needs_return()
  c52d51d67452 sched/core: Handle "blocked_on" clearing for wakeups in ttwu_runnable()


I just moved this further because I think it is an important bit to
handle the return migration vs wakeup of blocked donor. This too
has only been modified to resolve conflicts and nothing more.

  9db85fb35c22 sched: Have try_to_wake_up() handle return-migration for PROXY_WAKING case


These are two small trivial fixes - one that already exists in your
tree and is required for using proxy_resched_idle() from
proxy_needs_return() and the other to clear "p->blocked_on" when a
wakeup races with __schedule():

  0d6a01bb19db sched/core: Clear "blocked_on" relation if schedule races with wakeup
  fd60c48f7b71 sched: Avoid donor->sched_class->yield_task() null traversal

Everything before this is same as what is in your tree.

The bottom ones have the most information and the commit messages
get brief as we move to top but I believe there is enough context
in comments + commit log to justify these changes. Some may
actually have too much context but I've dumped my head out.

I'll freeze this branch and use a WIP like yours if and when I
manage to crash and burn these bits.


I know you are already oversubscribed so please take a look on a
best effort basis. I can also resend this as a separate series
once v26 lands if there is enough interest around.

Sorry for the dump and thank you again for patiently working on
this. Much appreciated _/\_

-- 
Thanks and Regards,
Prateek