Re: [PATCH v23 6/9] sched: Handle blocked-waiter migration (and return migration)

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

Hello John,

On 11/20/2025 7:30 AM, John Stultz wrote:
>> Ok, so you're suggesting maybe putting the
>>     if (task_on_rq_migrating(owner))
>> case ahead of the
>>     if (owner_cpu != this_cpu)
>> check?
>>
>> Let me give that a whirl and see how it does.
> 
> That said, thinking another second on it, I also realize once we
> decide to proxy_migrate, there is always the chance the owner gets
> migrated somewhere else. So we can check task_on_rq_migrating() but
> then right after we check that it might be migrated, and we can't
> really prevent this.  And in that case, doing the proxy-migration to
> the wrong place will be ok, as that cpu will then bounce the tasks to
> the owner's new cpu.
> 
> Hopefully this would be rare though. :)

Ack! I was just thinking of some extreme scenarios. We can probably
think about it if and when we run into a problem with it :)

That said, once we decide to move the first donors to owner's CPU
should we task some care to retain the owner on the same CPU as much
as possible - take it out of the purview of load balancing and only
move it if the owner is no long runnable on that CPU as a result of
affinity changes?

-- 
Thanks and Regards,
Prateek