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

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello John,

On 9/16/2026 11:53 AM, John Stultz wrote:
> On Tue, Sep 15, 2026 at 11:10 PM K Prateek Nayak <kprateek.nayak@amd.com> 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@amd.com> 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?

Lock nesting optimizations only work if we fully block delayed tasks
at the very least.

The only optimization I think which might work readily with your
series is proxy_enqueue_on_owner() bits in Patch 6 with:

activate_task(rq, p, flags)
{

    if (sched_proxy_exec()) {
        WRITE_ONCE(p->on_rq, TASK_ON_RQ_MIGRATING);

        /*
         * Once p->on_rq != 0, donors cannot queue on this task.
         * pairs with smp_mb() in proxy_enqueue_on_owner() that
         * orders list addition against owner's ->on_rq check.
         */
        smp_mb();
    }

    if (list_empty(&p->blocked_head))
        __activate_task(rq, p, flags);

    guard(raw_spinlock)(p->blcoked_lock);

    /* Slow-path */
}

Trades off needing to acquire blocked_lock always with an
ordered store instead. Also depends on the first 3 fixes from this
series to handle p->on_rq = MIGRATING properly on the
ttwu_do_activate() path.

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

I think so but I can take a stab at it and send out next version
re-based just before / after proxy futex bits.

-- 
Thanks and Regards,
Prateek