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

[John Stultz]

On Tue, Sep 15, 2026 at 11:10 PM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> 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:
> > 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.
>

Ok. I'd like to try to make more progress moving the sleeping owner
enqueuing upstream as soon as possible, so deciding to push forward
with my big patch or migrate to focusing on your set would be a good
call to make quickly here.

Your lock nesting optimization at the end seems like it might still be
applicable with my patch, no? Maybe we can pull that in at least?

I'm also wondering if trying to refactor the is_linked bits in after
my change might make sense, though I suspect that will require the
_MIGRATING flag dependencies?

thanks
-john