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

[Tejun Heo <tj@kernel.org>]

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.

Thanks.

--
tejun