Re: [PATCH 3/3] sched_ext: Allow scx_bpf_reenqueue_local() to be called from anywhere

[Peter Zijlstra]

On Fri, Oct 24, 2025 at 02:18:49PM -1000, Tejun Heo wrote:
> The ops.cpu_acquire/release() callbacks are broken - they miss events under
> multiple conditions and can't be fixed without adding global sched core hooks
> that sched maintainers don't want. They also aren't necessary as BPF schedulers
> can use generic BPF mechanisms like tracepoints to achieve the same goals.
> 
> The main use case for cpu_release() was calling scx_bpf_reenqueue_local() when
> a CPU gets preempted by a higher priority scheduling class. However, the old
> scx_bpf_reenqueue_local() could only be called from cpu_release() context.

I'm a little confused. Isn't this the problem where balance_one()
migrates a task to the local rq and we end up having to RETRY_TASK
because another (higher) rq gets modified?

Why can't we simply re-queue the task in the RETRY_TASK branch --
effectively undoing balance_one()?


Relying on hooking into tracepoints seems like a gruesome hack.