Re: [PATCH 1/2] sched_ext: Add ops.sub_child_ecaps_updated() to report a child's effective cap changes

[Tejun Heo <tj@kernel.org>]

Hello, Andrea.

On Fri, Oct 09, 2026 at 01:17:15PM +0200, Andrea Righi wrote:
> Should ops.sub_child_ecaps_updated() still be delivered to the parent when the
> child is bypassing but the parent is not?
>
> For example, the shared pool may rotate away from a bypassing child. IIUC, its
> PERF revoke takes effect at the next dispatch, but the child's bypass state
> suppresses the parent notification too. If the child is being disabled, it never
> leaves bypass, so the parent only gets ops.sub_detach() and cannot tell when the
> revoke took effect.
>
> Could we notify the parent when the revoke takes effect, even if the child is
> bypassing, while continuing to defer the child's own notification until it
> leaves bypass?

A child can't enter and stay in bypass on its own. It bypasses during its
own enable, which is lifted and replayed, during its own disable, or when
the whole hierarchy is bypassing and so is the parent. That leaves disable.
v1 reported the revokes of a disabling child and it got nasty because the
calling context differs from the sync path: the dispatch kfuncs needed their
context set up outside the dispatch path, the nested sub dispatch had to be
gated, and keeping the report clear of the PM bypass took a lock that could
stall a suspend. The simpler contract that works is that ops.sub_detach()
covers a disabling child. All of the child's caps are gone by the time it
runs, so the parent restores what it delegated from there.

Thanks.

--
tejun