Re: [RFC PATCH 09/16] sched/core: Track CPU where the task was blocked on

[John Stultz]

On Tue, Aug 25, 2026 at 11:32 PM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
>
> Track the CPU where task was blocked on when running with
> sched_proxy_exec().
>
> This is used to re-direct the activation of blocked donors queued on the
> blocked_head via the said CPU in the activation slowpath that will be
> added in the subsequent patches.

I'm a little confused on this, as the cpu the task was blocked on
doesn't intuitively have much bearing on where we'd want to activate
it, when a sleeping owner wakes up.

When a lock owner sleeps, all the chains of tasks waiting on that lock
(directly or not), will be enqueued on that sleeping owner.

In my patch, when the sleeping owner wakes up, it may or may not wake
up on the cpu it was dequeued from.  It seems we would want to enqueue
all of those blocked tasks onto the same runqueue where we activated
the owner, so they are all present on the same rq to be selected as a
donor to potentially run the owner and release the lock.

Since its like there is a likely chance the sleeping owner will wake
elsewhere (It looks like proxy_activate_blocked_task() in the later
patch effectively overrides the activation on the given rq and instead
wakes the tasks on the blocked_cpu),  won't this end up activating the
chain of blocked waiters on the wrong cpu (forcing them all to be
immediately proxy migrated over)?


> p->wake_cpu or task_cpu() is not sufficient for this purpose since
> p->wake_cpu is not stable when !task_on_rq_queued() and there is a
> window between set_task_cpu() and activet_blocked_task() in the wakeup
> path that needs to be plugged in.

Sorry if I'm being dim here.

Do you have more details on this? Was my patch prone to the same issue
you're avoiding in the second item here?

thanks
-john