Re: [RFC PATCH 00/16][PoC] sched/core: Alternate approach to sleeping-owner handling in PROXY_EXEC

[John Stultz]

On Tue, Aug 25, 2026 at 11:29 PM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
>
> I had promised John I would share an insane idea if I got it
> working(ish) so this RFC presents an alternate approach to handle
> enqueued donor wakeup vs owner's chain-wakeup race via ttwu_runnable()
> path and make the activate path as light as possible for tasks that
> don't need to do a chain wakeup.
>
> The series essentially breaks down John's large patch at
> https://lore.kernel.org/lkml/20260807035232.1881495-9-jstultz@xxxxxxxxxx/
> into smaller chunks while introducing the new approach and fixing a few
> snags encountered along the way (Patch 1 - Patch 4 are fixes that can be
> discussed without getting into the rest of the RFC).
>
> Disclaimer: Series in not bisectible in any way at the moment - related
> bits are introduced together at and intermediate builds may fail.
>
> Introduction
> ============
>
> Handling sleeping owner requires proxy-chains to queue on the said owner
> and perform a chain activation when the blocked owner wakes up.
>
> Since a blocked donor can be woken up by another concurrent wake event,
> the activation path becomes complicated and wakeup has to take an extra
> lock (p->blocked_lock) to prevent any modifications to "p->blocked_head"
> and miss activating any blocked donors.
>
...
> Trade-off
> =========
>
> Advantages:
>
> o Only need to juggle blocked_lock(s) under a single rq_lock().
> o Re-use ttwu_runnable bit to handle removal of proxy donor.
> o No need to do get_task_stuct() / put_task_struct() juggling.
>
> Disadvantages:
>
> o Possible increased rq_lock contention on the chain-wakeup path but
>   those events are generally rare.
> o Lack of delayed task handling since the src_rq need to be locked
>   separately to migrate it.
>
> For the delayed handling, it is possible to use proxy_migrate_task() to
> move the task after blocking. Series does not implement this yet to
> limit the number of bad ideas.
>

Sorry again for being so slow to respond here!

The series definitely looks interesting, and it seems to be holding up
ok in testing.  Though figuring out how to refactor them so that they
are also bisectable looks like a real challenge (part of why my
sleeping-owner enqueuing is basically one big patch)!

That said, I can't say I've truly gotten my head fully around your
series yet. I've definitely had way more time with my change, so I'm a
little biased in feeling its somewhat more bounded (even though the
activate_blocked_waiters() function and the multiple lists of tasks
are very complicated).

My initial sense of the downsides here with your series are: It adds a
lot of new per-task state (blocked_cpu, is_linked/needs_rq_sync,
sched_migrated_on_blocking, lock_nesting) to keep track of, and some
of rules for the new state have dependencies
(sched_migrated_on_blocking is tied to is_linked), and leveraging the
ENQUEUE/DEQUEUE_MIGRATING flags feels a little subtle (I have often
gotten the ENQUEUE/DEQUEUE flags wrong in my patch series, and
unfortunately the general documentation around those flags is lagging
a bit, so this adds to it).

The locking being simpler is a clear benefit and definitely sound
appealing - though I do agree the rq_lock hold time in
proxy_activate_blocked_task() seems like it might be an issue.

I've got a few more questions on specific patches, so I'll reply there.

Again, it definitely is interesting and appears to be more integrated
into the scheduler logic, so I'd expect that will give us better
results then my maybe more isolated and tacked on activation logic.

Have you gotten a sense of what Peter thinks of it?

thanks
-john