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

From: K Prateek Nayak

Date: Wed Nov 19 2025 - 21:55:30 EST


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