Re: [PATCH 1/6] sched/proxy: Remove superfluous clear_task_blocked_in()
From: Peter Zijlstra
Date: Fri May 29 2026 - 04:56:06 EST
On Fri, May 29, 2026 at 12:15:09PM +0530, K Prateek Nayak wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index a125e65c35bb..fe903976fd09 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3764,28 +3764,28 @@ static inline void proxy_reset_donor(struct rq *rq)
> */
> static inline bool proxy_needs_return(struct rq *rq, struct task_struct *p)
> {
> - if (!p->is_blocked)
> - return false;
> -
> - /*
> - * Typically per __set_task_cpu(), task_cpu(p) == p->wake_cpu.
> - *
> - * However, proxy_set_task_cpu() is such that it preserves the
> - * original cpu in p->wake_cpu while migrating p for proxy reasons
> - * (possibly outside of the allowed p->cpus_ptr).
> - *
> - * Furthermore, migration_cpu_stop() / __migrate_swap_task(), will
> - * only set p->wake_cpu when !p->on_rq, and since here p->on_rq, this
> - * will not apply. But if it did, this check is the safe way around
> - * and would migrate.
> - */
> - if (task_cpu(p) == p->wake_cpu)
> + if (!task_is_blocked(p))
> return false;
>
> scoped_guard(raw_spinlock, &p->blocked_lock) {
> /* Task is waking up; clear any blocked_on relationship */
> __clear_task_blocked_on(p, NULL);
>
> + /*
> + * Typically per __set_task_cpu(), task_cpu(p) == p->wake_cpu.
> + *
> + * However, proxy_set_task_cpu() is such that it preserves the
> + * original cpu in p->wake_cpu while migrating p for proxy reasons
> + * (possibly outside of the allowed p->cpus_ptr).
> + *
> + * Furthermore, migration_cpu_stop() / __migrate_swap_task(), will
> + * only set p->wake_cpu when !p->on_rq, and since here p->on_rq, this
> + * will not apply. But if it did, this check is the safe way around
> + * and would migrate.
> + */
> + if (task_cpu(p) == p->wake_cpu)
> + return false;
> +
> /* If already current, don't need to return migrate */
> if (task_current(rq, p))
> return false;
Egads, this is terrible. This means all is_blocked tasks always end up
taking blocked_lock.
The other suggestion (in the other subthread) was to simply delay this
patch until the end. That seems far more sensible.
Anyway, let me go try and find your git tree and see what you ended up
with.