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

[Tejun Heo <tj@kernel.org>]

Hello, Kuba.

On Tue, Oct 20, 2026 at 06:02:36PM +0000, Kuba Piecuch wrote:
> 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.

What I don't like about ops.cpu_acquire/release() is that they track
whether the CPU is occupied by a sched_class higher than SCX, which seems
a bit out of scope for a sched_class. Wanting to know that is fine, but
it's global system state and would be better tracked by hooking into
system events than built into sched_ext. I don't think the
acquire/release semantics are a good fit for it either.

> 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.

If sched_switch isn't enough, how about adding a tracepoint which tracks
the sched_class currently in effect on each CPU? That should cover both
scx_pair and your use case, and would be useful outside sched_ext too.

Thanks.

--
tejun