Re: [PATCH 01/10] sched/core: Drop mutex locks before proxy rescheduling

[Andrea Righi]

Hi John,

On Fri, Jul 10, 2026 at 11:56:04AM -0700, John Stultz wrote:
> On Fri, Jul 10, 2026 at 1:39 AM Andrea Righi <arighi@xxxxxxxxxx> wrote:
> >
> > find_proxy_task() can call proxy_resched_idle() while holding a mutex
> > wait_lock and the blocked task lock. Guard cleanup does not run until
> > after the return expression is evaluated.
> >
> > proxy_resched_idle() invokes scheduling-class callbacks through
> > put_prev_set_next_task(). Calling those callbacks with the mutex locks
> > held prevents them from safely inspecting the proxy chain, as doing so
> > may require acquiring the same locks.
> >
> > This is a preparatory change to support proxy execution in sched_ext. It
> > leaves the guard scope before calling proxy_resched_idle() so sched_ext
> > callbacks can safely inspect the proxy chain.
> 
> Thanks again for sending these out!
> 
> So, I wanted to understand more the importance of the sched_ext logic
> being able to inspect the proxy chain?
> 
> I sort of roughly understand the argument that some sched_ext
> schedulers may not want to keep blocked tasks on the rq (effectively
> what the "Delegate proxy donor admission to BPF schedulers" patch
> does), but that doesn't require deep inspection.
> 
> This change seems to be needed for "Add proxy destination query
> kfuncs", where the commit message sounds reasonable, but as I think
> more on it, it doesn't look correct (I'll comment more on the patch),
> and I'm still confused a bit as to the purpose.
> 
> So can you describe the premise and a bit more detail as to why this
> is important?

Inspecting the proxy chain is not strictly required. A BPF scheduler can just
accept a blocked donor, enqueue it on its current CPU and let the core
proxy-exec path resolve and "virtually" migrate it as needed to the owner's CPU.

The motivation for providing a scx_bpf_task_proxy_cpu() kfunc is purely for
optimization reasons. By knowing the owner's CPU, a scheduler could make more
informed admission decisions. For example, it can inspect the task currently
running on the target CPU, determine whether the donor should take precedence
over the running task and kick that CPU to trigger a preemption. Without this
information, the scheduler can only enqueue the donor and wait until the task
running on the owner's CPU releases it (potentially adding up to one time slice
of latency).

That said, I don't see a correctness dependency on exposing this information.
If the latency-policy use case is not strong enough to justify the API, I'm
happy to drop the query kfuncs and this preparatory lock-scope change for now,
the blocked-donor admission support can stand on its own.

Thanks,
-Andrea