Re: [PATCH v2 03/10] sched/ext: Add a DL server for sched_ext tasks

[Tejun Heo <tj@kernel.org>]

On Mon, Jun 02, 2025 at 02:00:59PM -0400, Joel Fernandes wrote:
...
> @@ -2308,6 +2311,15 @@ static void enqueue_task_scx(struct rq *rq, struct task_struct *p, int enq_flags
>  	if (enq_flags & SCX_ENQ_WAKEUP)
>  		touch_core_sched(rq, p);
>  
> +	if (rq->scx.nr_running == 1) {
> +		/* Account for idle runtime */
> +		if (!rq->nr_running)
> +			dl_server_update_idle_time(rq, rq->curr, &rq->ext_server);
> +
> +		/* Start dl_server if this is the first task being enqueued */
> +		dl_server_start(&rq->ext_server);
> +	}

The following patch from Peter isn't upstream yet but SCX probably should do
something similar. Otherwise, the start/stop overhead can become pretty
expensive:

 https://lore.kernel.org/all/20250520094538.086709102@infradead.org/

Another thing which is worth considering is that while rq->nr_running based
test would work in a lot of cases, it won't work in all cases for SCX as the
BPF scheduler may choose to not dispatch to the particular CPU even if a
task is currently associated with it.

For example, a soft partitioning scheduler might change partition CPU
allocations after enqueue() is complete and a task may end up associated
with a CPU that's no longer in its partition and when dispatch() is called
from the CPU, the BPF scheduler may not consume that task. This can become a
problem for the dl server based forward progress guarantee as that task is
enabling the dl server only on the rq that it's currently associated with.

This shouldn't be too common and the proposed patch puts us back in the same
state as the original RT bandwidth control, so no need to hold this series
for this issue but I think the right solution would be adding an optional
SCX operation so that the BPF scheduler can decide which CPUs should be
running the dl server.

Thanks.

-- 
tejun