Re: [PATCH 1/2] sched_ext: Auto-register/unregister dl_server reservations

[Peter Zijlstra]

On Tue, May 26, 2026 at 06:42:48PM +0200, Andrea Righi wrote:
> @@ -6187,10 +6190,34 @@ static void scx_root_disable(struct scx_sched *sch)
>  	/*
>  	 * Invalidate all the rq clocks to prevent getting outdated
>  	 * rq clocks from a previous scx scheduler.
> +	 *
> +	 * Also re-balance the dl_server bandwidth reservations: detach
> +	 * ext_server (no more sched_ext tasks) and reinstate fair_server if it
> +	 * was previously detached because we were running in full mode.
> +	 *
> +	 * Unlike the enable path, this runs on a recovery path that cannot
> +	 * fail, so we use dl_server_swap_bw() to atomically free ext_server's
> +	 * bandwidth and reclaim it for fair_server under the same dl_b lock.
> +	 *
> +	 * The swap can still fail with -EBUSY if someone bumped ext_server's
> +	 * runtime via debugfs between enable and disable; in that narrow case
> +	 * both servers end up detached and we just WARN.
>  	 */
>  	for_each_possible_cpu(cpu) {
>  		struct rq *rq = cpu_rq(cpu);
> +
>  		scx_rq_clock_invalidate(rq);
> +
> +		scoped_guard(rq_lock_irqsave, rq) {
> +			update_rq_clock(rq);
> +			if (was_switched_all) {
> +				if (WARN_ON_ONCE(dl_server_swap_bw(&rq->ext_server,
> +								   &rq->fair_server)))
> +					pr_warn("failed to re-attach fair_server on CPU %d\n", cpu);

One option here, with the swap, is to reduce the fair servers bandwidth
to match the outgoing ext server. Then at least you end up with the fair
server running, rather than having it completely stopped.

But this is going to be a rather rare occurrence, and people will have
to go poke at the debugfs controls anyway if this happens, so maybe
that's just not worth the effort.

But I wanted to mention it...

> +			} else {
> +				dl_server_detach_bw(&rq->ext_server);
> +			}
> +		}
>  	}
>  
>  	/* no task is on scx, turn off all the switches and flush in-progress calls */