Re: [PATCH v33 4/7] sched/proxy: Set TASK_RUNNING when shortcuting return migration

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

Hello Andrea,

On 10/24/2026 2:06 PM, Andrea Righi wrote:
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 2cb42de255f7a..43ba76b5a3464 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -7028,6 +7028,7 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
>>  			clear_task_blocked_on(p, mutex);
>>  			if (task_current(rq, p) || p->wake_cpu == task_cpu(p)) {
>>  				p->is_blocked = 0;
>> +				WRITE_ONCE(p->__state, TASK_RUNNING);
>>  				return p;
>>  			}
>>  			goto activate;
> 
> This is basically an inlined ttwu_do_wakeup() without
> trace_sched_wakeup().
> 
>> @@ -7065,6 +7066,7 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
>>  			__clear_task_blocked_on(p, NULL);
>>  			if (task_current(rq, p) || p->wake_cpu == task_cpu(p)) {
>>  				p->is_blocked = 0;
>> +				WRITE_ONCE(p->__state, TASK_RUNNING);
>>  				return p;
>>  			}
>>  			goto activate;
> 
> Ditto.
> 
> Can we just call ttwu_do_wakeup(p)? It'd also avoid having two copies of
> the same state transition that can diverge.

That is a good idea but I wonder issuing a sched_wakeup trace without a
corresponding sched_waking trace will trip some tracing scripts.

That said having a __ttwu_do_wakeup() to consolidate all the task state
changes in indeed a good idea. It should technically look like a
__schedule() raced with a wakeup. Thoughts?

-- 
Thanks and Regards,
Prateek