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

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Jul 02, 2026 at 10:43:14AM +0530, K Prateek Nayak wrote:
> Hello John,
> 
> On 7/2/2026 3:15 AM, John Stultz wrote:
> > From: Vasily Gorbik <gor@linux.ibm.com>
> > 
> > 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@amd.com/
> 
> 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?

I am going to excuse myself and say I'll look at all this in about 4
weeks when I'm back from holidays.