Re: [PATCH v26 10/10] sched: Handle blocked-waiter migration (and return migration)

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello Steve,

On 3/27/2026 4:22 AM, Steven Rostedt wrote:
>> +#ifdef CONFIG_SCHED_PROXY_EXEC
>> +static inline void proxy_set_task_cpu(struct task_struct *p, int cpu)
>> +{
>> +	unsigned int wake_cpu;
>> +
>> +	/*
>> +	 * Since we are enqueuing a blocked task on a cpu it may
>> +	 * not be able to run on, preserve wake_cpu when we
>> +	 * __set_task_cpu so we can return the task to where it
>> +	 * was previously runnable.
>> +	 */
>> +	wake_cpu = p->wake_cpu;
>> +	__set_task_cpu(p, cpu);
>> +	p->wake_cpu = wake_cpu;
>> +}
>> +#endif /* CONFIG_SCHED_PROXY_EXEC */
> 
> Hmm, this is only used in proxy_migrate_task() which is also within a
> #ifdef CONFIG_SCHED_PROXY_EXEC block. Why did you put this function here
> and create yet another #ifdef block with the same conditional?
> 
> Couldn't you just add it just before where it is used?

If I have to take a guess, it is here because the full proxy stack makes
use of this for blocked owner bits and this was likely broken off from
that when it was one huge patch.

When activating the entire blocked_on chain when sleeping owner wakes
up, this is used for migrating the donors to the owner's CPU
(activate_blocked_waiters() on
johnstultz-work/linux-dev/proxy-exec-v26-7.0-rc5)

That needs to come before sched_ttwu_pending() which is just a few
functions down.

Maybe we can keep all the bits together for now and just use a
forward declaration later when those bits comes. Thoughts?

-- 
Thanks and Regards,
Prateek