Re: [RFC PATCH sched_ext/for-7.4 0/5] sched_ext: Make ops.cpu_acquire/release() reliable

[Kuba Piecuch <jpiecuch@google.com>]

Hi Tejun,

On Tue Oct 20, 2026 at 12:31 AM UTC, Tejun Heo wrote:
> I don't really see a lot of utility in ops.cpu_acquire/release(). As it
> currently stands, it doesn't add anything that can't be covered by IMMED,

That's true if the only thing you do from ops.cpu_release() is
re-enqueue the local DSQ. It may not be true if you're trying to do
other things like e.g. kicking the sibling CPU in scx_pair.

Fixing ops.cpu_release() would let us get rid of the sched_switch hack
in scx_pair, which we know isn't perfect at detecting CPU preemption
by a higher sched_class.

> and given how asynchronous the events are, I'm not sure an edge-triggered
> view of CPU availability is particularly useful. IMMED works because it's
> something the kernel can check and enforce. If there are holes in it,
> let's plug them, but I don't think the holes justify keeping or updating
> ops.cpu_acquire/release().

ops.cpu_acquire() is synchronously invoked in the dispatch path, and
ops.cpu_release() would be invoked when the sched_class of rq->donor
goes above ext_sched_class, so either in __schedule() or when changing
the sched_class of a running task. It doesn't strike me as particularly
asynchronous.

Part of my motivation is Google's BPF schedulers, which are composed
of subschedulers, and we explicitly track which CPU is owned by which
subscheduler. Having a reliable CPU preemption callback would help with
porting them over to sched_ext.

> Can you please send the IMMED fixes separately?

Will do.

Thanks,
Kuba