linux-kernel - Re: [PATCH 06/14] 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: <aPY-QOXV5USEHVIq@gpd4>
Date: Mon, 20 Oct 2025 15:50:56 +0200
From: Andrea Righi <arighi@...dia.com>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
	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>,
	Joel Fernandes <joelagnelf@...dia.com>, Tejun Heo <tj@...nel.org>,
	David Vernet <void@...ifault.com>,
	Changwoo Min <changwoo@...lia.com>, Shuah Khan <shuah@...nel.org>,
	sched-ext@...ts.linux.dev, bpf@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Luigi De Matteis <ldematteis123@...il.com>
Subject: Re: [PATCH 06/14] sched_ext: Add a DL server for sched_ext tasks

Hi Juri,

On Mon, Oct 20, 2025 at 01:58:50PM +0200, Juri Lelli wrote:
> Hi!
> 
> On 17/10/25 11:25, Andrea Righi wrote:
> > From: Joel Fernandes <joelagnelf@...dia.com>
> > 
> > sched_ext currently suffers starvation due to RT. The same workload when
> > converted to EXT can get zero runtime if RT is 100% running, causing EXT
> > processes to stall. Fix it by adding a DL server for EXT.
> > 
> > A kselftest is also provided later to verify:
> > 
> > ./runner -t rt_stall
> > ===== START =====
> > TEST: rt_stall
> > DESCRIPTION: Verify that RT tasks cannot stall SCHED_EXT tasks
> > OUTPUT:
> > TAP version 13
> > 1..1
> > ok 1 PASS: CFS task got more than 4.00% of runtime
> > 
> > [ arighi: drop ->balance() now that pick_task() has an rf argument ]
> > 
> > Cc: Luigi De Matteis <ldematteis123@...il.com>
> > Co-developed-by: Andrea Righi <arighi@...dia.com>
> > Signed-off-by: Andrea Righi <arighi@...dia.com>
> > Signed-off-by: Joel Fernandes <joelagnelf@...dia.com>
> > ---
> >  kernel/sched/core.c     |  3 +++
> >  kernel/sched/deadline.c |  2 +-
> >  kernel/sched/ext.c      | 51 +++++++++++++++++++++++++++++++++++++++--
> >  kernel/sched/sched.h    |  2 ++
> >  4 files changed, 55 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 096e8d03d85e7..31a9c9381c63f 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -8679,6 +8679,9 @@ void __init sched_init(void)
> >  		hrtick_rq_init(rq);
> >  		atomic_set(&rq->nr_iowait, 0);
> >  		fair_server_init(rq);
> > +#ifdef CONFIG_SCHED_CLASS_EXT
> > +		ext_server_init(rq);
> > +#endif
> >  
> >  #ifdef CONFIG_SCHED_CORE
> >  		rq->core = rq;
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index 0680e0186577a..3c1fd2190949e 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/deadline.c
> > @@ -1504,7 +1504,7 @@ static void update_curr_dl_se(struct rq *rq, struct sched_dl_entity *dl_se, s64
> >  	 * The fair server (sole dl_server) does not account for real-time
> 
> Fair server is not alone anymore. :))
> 
> Please update the comment as well.
> 
> >  	 * workload because it is running fair work.
> >  	 */
> > -	if (dl_se == &rq->fair_server)
> > +	if (dl_se->dl_server)
> >  		return;
> >  
> >  #ifdef CONFIG_RT_GROUP_SCHED
> 
> ...
> 
> > @@ -1487,6 +1499,11 @@ static bool dequeue_task_scx(struct rq *rq, struct task_struct *p, int deq_flags
> >  	sub_nr_running(rq, 1);
> >  
> >  	dispatch_dequeue(rq, p);
> > +
> > +	/* Stop the server if this was the last task */
> > +	if (rq->scx.nr_running == 0)
> > +		dl_server_stop(&rq->ext_server);
> > +
> 
> Do we want to use the delayed stop behavior for scx-server as we have
> for fair-server? Wonder if it's a matter of removing this explicit stop
> and wait for a full period to elapse as we do for fair. It should reduce
> timer reprogramming overhead for scx as well.

So, IIUC we could just remove this explicit dl_server_stop() and the server
would naturally stop at the end of its current deadline period, if there
are still no runnable tasks, right?

In that case it's worth a try.

Thanks,
-Andrea