Re: [PATCH v30 3/7] sched/core: Don't proxy-exec unmatched cookie lock owners

[John Stultz]

On Wed, Jul 1, 2026 at 10:13 PM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> On 7/2/2026 3:15 AM, John Stultz wrote:
> > From: Vasily Gorbik <gor@xxxxxxxxxxxxx>
> >
> > Core scheduling chooses a core-wide cookie before __schedule()
> > installs the next task. With proxy-exec enabled, that task becomes the
> > donor/scheduling context, and find_proxy_task() may then replace the
> > execution context with the runnable mutex owner. If its cookie differs
> > from the selected core cookie, running it would bypass core scheduling's
> > cookie selection.
> >
> > When the final mutex owner found by find_proxy_task() does not match the
> > selected core cookie, stop proxying the donor. If the current execution
> > context is already in the blocked chain, fall back to idle like the
> > existing proxy-exec retry paths do. Otherwise deactivate the donor and
> > let __schedule() pick again. The mutex owner can be picked later under
> > its own cookie.
>
> So I had a interesting (maybe a bit insane) way to make this work by
> using the lock owner for rq->core_cookie when the blocked donor is
> the core-wide preferred selection.
>
> I was waiting on Peter's core-sched cleanup to post an official series
> but it is currently present as one big RFC patch at
> https://lore.kernel.org/lkml/9ceb2af0-33c6-40ca-b855-5167a9c5ae0f@xxxxxxx/
>

Oh! Very interesting! My apologies for somehow having overlooked this mail!


> I can streamline that more on top of current tip to do it all in
> pick_next_task() but the bigger question is, is it worth all the
> complexity?
>
> John, Peter, what do you think?
>
> [..snip..]
>
> > @@ -7004,6 +7004,14 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
> >               owner->blocked_donor = p;
> >       }
> >       WARN_ON_ONCE(owner && !owner->on_rq);
> > +
> > +     if (owner && !sched_cpu_cookie_match(rq, owner)) {
> > +             if (curr_in_chain)
> > +                     return proxy_resched_idle(rq);
> > +             p = donor; /* Deactivate the donor, not the runnable owner */
> > +             clear_task_blocked_on(p, NULL);
> > +             goto deactivate;
> > +     }
>
> Otherwise, this is acceptable if we don't want to touch core-sched
> bits juts yet.

Vasily's patch I think is a reasonable short-term solution just to
avoid breaking core-scheduling with proxy, but it's not a great
solution as it just disables proxy in the problematic cases.

So I'm very interested in your proposal, as I was thinking I'd have to
pick folks' brains at LPC to figure out a better approach. But it
might be worth taking Vasily's patch while yours gets polished and
tested?
I'll try pulling your change in to test with my full tree.

thanks
-john