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

[Peter Zijlstra <peterz@infradead.org>]

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?