Re: [PATCH 2/6] sched_ext: Free a sub-scheduler a grace period after discarding its ecaps syncs

[Andrea Righi <arighi@nvidia.com>]

On Sat, Oct 17, 2026 at 10:16:01PM -1000, Tejun Heo wrote:
> Hello, Andrea.
> 
> On Sun, Oct 18, 2026 at 08:56:33AM +0200, Andrea Righi wrote:
> > This is called for every possible CPU from the free path of every sched,
> > including a root without sub-scheds, whose nodes are never queued. With the lock
> > moved ahead of the test, every scheduler unload now takes all the rq locks with
> > irqs off, which on a large machine can be a lot of lock traffic.
> 
> The loop this replaces also took each rq lock once, and attach and detach
> already cycle through all the rq locks several times, e.g. in scx_bypass()
> and ecaps_report(). Cycling through the rq locks isn't that expensive.
> 
> > The first grace period has passed by now, so nothing queues the node again, and
> > a node taken by an in-flight batch still reads as on-list. So, can we keep the
> > lockless test in front?
> 
> A node taken by an in-flight batch doesn't read as on-list.
> __scx_process_sync_ecaps() calls init_llist_node() on each node before it
> writes the pcpu and calls the ops, so the node being processed reads as
> off-list while the batch is still using it. The lockless test would still be
> safe, as the second grace period is what waits for the batch, but the
> rationale is incorrect, which is kinda par for the course given the
> complexity of this path. I'd much rather keep it as dumb as possible.

Makes sense, thanks for clarifying.

-Andrea