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

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

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?

[..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.

>  	return owner;
>  
>  deactivate:

-- 
Thanks and Regards,
Prateek