linux-kernel - Re: [PATCH v2 03/10] sched/ext: Add a DL server for sched

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aD5Ai3xJdnV5SxG0@slm.duckdns.org>
Date: Mon, 2 Jun 2025 14:23:39 -1000
From: Tejun Heo <tj@...nel.org>
To: Joel Fernandes <joelagnelf@...dia.com>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Valentin Schneider <vschneid@...hat.com>,
	David Vernet <void@...ifault.com>, Andrea Righi <arighi@...dia.com>,
	Changwoo Min <changwoo@...lia.com>,
	Luigi De Matteis <ldematteis123@...il.com>
Subject: Re: [PATCH v2 03/10] sched/ext: Add a DL server for sched_ext tasks

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