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

[K Prateek Nayak]

Hello John,

On 9/16/2026 10:52 AM, John Stultz wrote:
> 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.

Ack! My original thinking was it is only done in the slow-path and
is only held for a few ->on_rq and list manipulations so I might be
able to get away with that small overhead.

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

Looking forward to those.

> 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?

I think Peter is slowly getting through the more stable stuff first
and may arrive at this at some point but I'll try to get a word in
at LPC if he is planning on attending.

That said, knowing Peter, I have a hunch he might like your approach
better since it handles delayed tasks too (tasks may be eligible at the
time of chain-wakeup), does not add stuff into ttwu_runnable(), and does
not have the insane (DEQUEUE_SLEEP | DEQUEUE_MIGRATING) behavior which
has larger implications for PELT tracking and SCHED_DEADLINE.

I sent out the RFC since it makes for an interesting discussion but I
have a feeling lot more things need ironing out if w go this way but
I can always do it later after the stuff from you and Suleiman lands
once I can prove some benefit.

-- 
Thanks and Regards,
Prateek