Re: [PATCH v25 2/9] sched: Minimise repeated sched_proxy_exec() checking

[K Prateek Nayak]

Hello John,

On 3/13/2026 8:00 AM, John Stultz wrote:
> Peter noted: Compilers are really bad (as in they utterly refuse)
> optimizing (even when marked with __pure) the static branch
> things, and will happily emit multiple identical in a row.
> 
> So pull out the one obvious sched_proxy_exec() branch in
> __schedule() and remove some of the 'implicit' ones in that
> path.
> 
> Suggested-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Signed-off-by: John Stultz <jstultz@xxxxxxxxxx>

Feel free to include:

Reviewed-by: K Prateek Nayak <kprateek.nayak@xxxxxxx>

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index d86d648a75a4b..84c61496fa263 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6597,11 +6597,7 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
>  	struct mutex *mutex;
>  
>  	/* Follow blocked_on chain. */
> -	for (p = donor; task_is_blocked(p); p = owner) {
> -		mutex = p->blocked_on;
> -		/* Something changed in the chain, so pick again */
> -		if (!mutex)
> -			return NULL;

Previously we used to return NULL here when "p->blocked_on" turned NULL
between the check in the loop condition and the read here but from my
analysis on v24, with PROXY_WAKING, "p->blocked_on" can never transition
to NULL with rq_lock() held for a queued task (it can only transition
from a valid mutex to PROXY_WAKING outside the rq_lock, both of which
are not NULL) so we should never hit this condition now with the new
state and this should be safe :-)


> +	for (p = donor; (mutex = p->blocked_on); p = owner) {
>  		/*
>  		 * By taking mutex->wait_lock we hold off concurrent mutex_unlock()
>  		 * and ensure @owner sticks around.

-- 
Thanks and Regards,
Prateek