linux-kernel - Re: [PATCH v2] sched/deadline: Reset dl

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] [day] [month] [year] [list]
Message-ID: <aXoSFOONWJmdyCQB@gpd4>
Date: Wed, 28 Jan 2026 14:41:40 +0100
From: Andrea Righi <arighi@...dia.com>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: 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>, Tejun Heo <tj@...nel.org>,
	Joel Fernandes <joelagnelf@...dia.com>,
	David Vernet <void@...ifault.com>,
	Changwoo Min <changwoo@...lia.com>,
	Daniel Hodges <hodgesd@...a.com>, sched-ext@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] sched/deadline: Reset dl_server execution state on
 stop

On Wed, Jan 28, 2026 at 09:50:36AM +0000, Gabriele Monaco wrote:
> 2026-01-27T18:55:02Z Andrea Righi <arighi@...dia.com>:
> > Unfortunately checking only runtime <= 0 isn't enough for the sched_ext DL
> > server case:
> >
> > # Runtime of EXT task (PID 2025) is 0.000000 seconds
> > # Runtime of RT task (PID 2026) is 4.990000 seconds
> > # EXT task got 0.00% of total runtime
> > not ok 2 FAIL: EXT task got less than 4.00% of runtime
> >
> > With the unconditional reset the EXT task gets 5% of the bandwidth. I'll
> > add some debugging to figure out exactly what is happening.
> 
> Thanks for testing it. That's quite strange..
> 
> I run your test on a kernel without ext server, as far as I understand, the test is kinda indirectly checking also the fair server and that does not fail, right?
> At least that's what I get on an arm64 machine with 128 CPUs.

That's right, withtout the ext server, the EXT task is supposed to starve.

And yes, the test is also checking the fair server, just to make sure we're
not breaking anything in fair while we're loading / unloading the BPF
scheduler.

> 
> After letting the test continue on failure I get:
> 
> # # Runtime of FAIR task (PID 22503) is 0.240000 seconds
> # # Runtime of RT task (PID 22504) is 4.750000 seconds
> # # FAIR task got 4.81% of total runtime
> # ok 1 PASS: FAIR task got more than 4.00% of runtime
> # TAP version 13
> # 1..1
> # # Runtime of EXT task (PID 22511) is 0.020000 seconds
> # # Runtime of RT task (PID 22512) is 4.970000 seconds
> # # EXT task got 0.40% of total runtime
> # not ok 2 FAIL: EXT task got less than 4.00% of runtime
> # TAP version 13
> # 1..1
> # # Runtime of FAIR task (PID 22518) is 0.240000 seconds
> # # Runtime of RT task (PID 22519) is 4.750000 seconds
> # # FAIR task got 4.81% of total runtime
> # ok 3 PASS: FAIR task got more than 4.00% of runtime
> # TAP version 13
> # 1..1
> # # Runtime of EXT task (PID 22525) is 0.000000 seconds
> # # Runtime of RT task (PID 22526) is 4.990000 seconds
> # # EXT task got 0.00% of total runtime
> # not ok 4 FAIL: EXT task got less than 4.00% of runtime
> # ok 24 rt_stall #
> 
> Mind that it's expected for the ext task to starve (I didn't apply the patches enabling the server).

Correct, this makes sense.

> 
> After adding all your patches [1], also the ext passes the test (i.e. gets boosted just fine).
> 
> I tried disabling all CPUs but CPU0 and run the same test and it hung (bad sign), then I also enabled CPU1 (total 2 CPUs online) and again I see both fair and ext getting their share.
> 
> What am I missing here?

With the ext server patchset [1], without resetting dl_defer_running in
dl_server_stop() I get this:

$ sudo ./runner -t rt_stall
===== START =====
TEST: rt_stall
DESCRIPTION: Verify that RT tasks cannot stall SCHED_EXT tasks
OUTPUT:
TAP version 13
1..1
# Runtime of FAIR task (PID 1993) is 0.250000 seconds
# Runtime of RT task (PID 1994) is 4.740000 seconds
# FAIR task got 5.01% of total runtime
ok 1 PASS: FAIR task got more than 4.00% of runtime
[   28.494515] sched_ext: BPF scheduler "rt_stall" enabled
TAP version 13
1..1
# Runtime of EXT task (PID 1996) is 0.240000 seconds
# Runtime of RT task (PID 1997) is 4.740000 seconds
# EXT task got 4.82% of total runtime
ok 2 PASS: EXT task got more than 4.00% of runtime
[   33.538466] sched_ext: BPF scheduler "rt_stall" disabled (unregistered from user space)
TAP version 13
1..1
# Runtime of FAIR task (PID 1999) is 0.000000 seconds
# Runtime of RT task (PID 2000) is 4.990000 seconds
# FAIR task got 0.00% of total runtime
not ok 3 FAIL: FAIR task got less than 4.00% of runtime
# Planned tests != run tests (1 != 3)
# Totals: pass:2 fail:1 xfail:0 xpass:0 skip:0 error:0

The fair server works, ext server works, but once the ext server is
unloaded, the fair server is broken.

If I apply the fix to reset dl_defer_running in dl_server_stop() on top of
[1], the test is passing:

$ sudo ./runner -t rt_stall
===== START =====
TEST: rt_stall
DESCRIPTION: Verify that RT tasks cannot stall SCHED_EXT tasks
OUTPUT:
TAP version 13
1..1
# Runtime of FAIR task (PID 1965) is 0.240000 seconds
# Runtime of RT task (PID 1966) is 4.740000 seconds
# FAIR task got 4.82% of total runtime
ok 1 PASS: FAIR task got more than 4.00% of runtime
[   25.307989] sched_ext: BPF scheduler "rt_stall" enabled
TAP version 13
1..1
[   26.257788] hrtimer: interrupt took 112519 ns
# Runtime of EXT task (PID 1968) is 0.250000 seconds
# Runtime of RT task (PID 1969) is 4.750000 seconds
# EXT task got 5.00% of total runtime
ok 2 PASS: EXT task got more than 4.00% of runtime
[   30.344700] sched_ext: BPF scheduler "rt_stall" disabled (unregistered from user space)
TAP version 13
1..1
# Runtime of FAIR task (PID 1971) is 0.250000 seconds
# Runtime of RT task (PID 1972) is 4.750000 seconds
# FAIR task got 5.00% of total runtime
ok 3 PASS: FAIR task got more than 4.00% of runtime
[   35.373585] sched_ext: BPF scheduler "rt_stall" enabled
TAP version 13
1..1
# Runtime of EXT task (PID 1975) is 0.240000 seconds
# Runtime of RT task (PID 1976) is 4.740000 seconds
# EXT task got 4.82% of total runtime
ok 4 PASS: EXT task got more than 4.00% of runtime
[   40.403697] sched_ext: BPF scheduler "rt_stall" disabled (unregistered from user space)
ok 1 rt_stall #
=====  END  =====


=============================

RESULTS:

PASSED:  1
SKIPPED: 0
FAILED:  0

> 
> Thanks,
> Gabriele
> 
> [1] - https://lore.kernel.org/lkml/20260126100050.3854740-1-arighi@nvidia.com
> 

Just to make sure we're testing the same thing, I'm currently using
https://git.kernel.org/pub/scm/linux/kernel/git/arighi/linux.git, branch
scx-dl-server.

I'm running this test inside virtme-ng:
  $ vng -vb --config tools/testing/selftests/sched_ext/config
  $ vng -v -- tools/testing/selftests/sched_ext/runner -t rt_stall

Thanks,
-Andrea