Re: [PATCH v26 00/10] Simple Donor Migration for Proxy Execution

Peter Zijlstra
2026-04-03T11:28:23Z

On Fri, Apr 03, 2026 at 03:55:22PM +0530, K Prateek Nayak wrote:
> >> @@ -4256,6 +4277,15 @@ int try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
> >> */
> >> smp_cond_load_acquire(&p->on_cpu, !VAL);
> >>
> >> + /*
> >> + * We never clear the blocked_on relation on proxy_deactivate.
> >> + * If we don't clear it here, we have TASK_RUNNING + p->blocked_on
> >> + * when waking up. Since this is a fully blocked, off CPU task
> >> + * waking up, it should be safe to clear the blocked_on relation.
> >> + */
> >> + if (task_is_blocked(p))
> >> + clear_task_blocked_on(p, NULL);
> >> +
> >
> > Aah, yes! This is when find_proxy_task() hits deactivate() for us and we
> > skip ttwu_runnable(). We still need to clear ->blocked_on.

I wonder, should we have proxy_deactivate() do this instead?

> >
> >> cpu = select_task_rq(p, p->wake_cpu, &wake_flags);
> >> if (task_cpu(p) != cpu) {
> >> if (p->in_iowait) {
> >> @@ -6977,6 +7007,10 @@ static void __sched notrace __schedule(int sched_mode)
> >> switch_count = &prev->nvcsw;
> >> }
> >>
> >> + /* See: https://github.com/kudureranganath/linux/commit/0d6a01bb19db39f045d6f0f5fb4d196500091637 */
> >> + if (!prev_state && task_is_blocked(prev))
> >> + clear_task_blocked_on(prev, NULL);
> >> +
> >
> > This one confuses me, ttwu() should never results in ->blocked_on being
> > set.
>
> This is from the signal_pending_state() in try_to_block_task() putting
> prev to TASK_RUNNING while still having p->blocked_on.

Ooh, I misread that. I saw that set_task_blocked_on_waking(, NULL) in
there and though it would clear. Damn, sometimes reading is so very
hard...

Anyhow, with my changes on, try_to_block_task() is only ever called from
__schedule() on current. This means this could in fact be
clear_task_blocked_on(), right?