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

[Andrea Righi <arighi@nvidia.com>]

On Fri, Oct 09, 2026 at 10:04:11AM -1000, Tejun Heo wrote:
> 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.

Ah yes, it makes sense, disable is the only case where a child remains bypassed
while the parent is active. Handling final cleanup in ops.sub_detach() is
reasonable given the different calling context.

Reviewed-by: Andrea Righi <arighi@nvidia.com>

Thanks,
-Andrea