Re: [PATCH v5 sched_ext/for-7.3 28/33] sched_ext: Route ops.update_idle() to sub-schedulers and re-notify owed scheds

Hello, Andrea.

On Tue, Jul 14, 2026 at 08:18:20AM +0200, Andrea Righi wrote:
> So, this makes every real idle/busy transition walk the whole scheduler
> hierarchy and potentially invoke ops.update_idle() for every cap-holding
> scheduler while the rq lock is held and IRQs are disabled?
>
> This becomes O(number of cap-holding schedulers) BPF callbacks per idle
> transition.
>
> I haven't benchmarked this, so I'm not sure if it's a valid performance concern.
> We don't have to fix this now, it can be a future improvement. In that case, if
> we prove that we have a real bottleneck here, would it make sense to maintain a
> per-rq list of schedulers that both hold effective SCX_CAP_BASE and implement
> ops.update_idle()?

If this becomes an actual problem, we can add an opt-out for update_idle
notifications and maintain the list of scheds that are subscribing. With
shallow nesting and most cpus granted exclusively, which are the expected
initial use cases, I don't expect this to be a problem in practice. We'll
see.

> Also, for the root-only case, would it be worth keeping the old direct
> ops.update_idle() path behind a static key which is enabled while any
> sub-scheduler is attached?

Yeah, will gate this and the other sub-sched hot paths behind a static
key in follow-up patches.

Thanks.

--
tejun