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

K Prateek Nayak
2026-03-15T17:02:14Z

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@infradead.org>
> Signed-off-by: John Stultz <jstultz@google.com>

Feel free to include:

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

> 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