mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v3 00/24] sched/deadline: bandwidth accounting fixes and selftests
@ 2026-11-05 19:33 Mathieu Desnoyers
  2026-11-05 19:33 ` [PATCH v3 01/24] sched: Fix cpuset_mutex double unlock in __sched_setscheduler() Mathieu Desnoyers
                   ` (24 more replies)
  0 siblings, 25 replies; 38+ messages in thread
From: Mathieu Desnoyers @ 2026-11-05 19:33 UTC (permalink / raw)
  To: juri.lelli, peterz, mingo, vincent.guittot
  Cc: linux-kernel, Mathieu Desnoyers, dietmar.eggemann, rostedt,
	bsegall, mgorman, vschneid, kprateek.nayak, luca.abeni,
	mathieu.poirier, longman, ridong.chen, tj, hannes, mkoutny,
	shuah, bigeasy, clrkwllms, parri.andrea, m.szyprowski,
	kayracizmeci, weihengqiuu, cgroups, linux-kselftest,
	linux-rt-devel

Hi Ingo, Juri,

Please find in this series twenty fixes to SCHED_DEADLINE bandwidth
accounting on v7.4-rc1, followed by the sched_debug output of a
runqueue's deadline bandwidth and the three selftests that catch the
fixes: twenty-four patches, the fixes first, as you asked, so that
stable can take patches 1 to 20 and stop.

Patch 1 is Andrea Parri's fix of the cpuset_mutex double unlock, posted
on Nov 2 and reviewed by Waiman, Kayra and Juri, carried here unchanged
with its tags because patch 13 builds on it; v2's patch 19 was the same
fix. Take it from whichever route you prefer.

This revision replaces your four fixes of sched/urgent, Juri, which Ingo
dropped after the first of them crashed Marek Szyprowski's hotplug test.
They went four ways. The stale root domain of a cpuset transfer (1/4) is
fixed by patch 14, which records the root domain that counts a task's
bandwidth instead of deriving it from the task's mask, and reports to
Weiheng Qiu's thread; a mask has no active CPU during hotplug, which is
what crashed. The total_bw leak of a task leaving the class asleep (2/4)
is patch 8, reworked with the v2 fix of the double release it caused,
and without your Signed-off-by, which is yours to add back. The
KEEP_PARAMS refusal (3/4) is patch 2, with the v2 fixes of its placement
and of the policy change it let through. The refusal of SCHED_DEADLINE
on exited tasks (4/4) is patch 9, yours, extended to a task of the class
leaving it, which decrements its cpuset's count of deadline tasks a
second time. Marek tested v2 on the board that crashed, and found it
fixed; v3 differs enough that his Tested-by is not on a patch.

One word before the details: I am at home with the concepts behind
SCHED_DEADLINE, but not with its implementation, and these patches were
written with an LLM assistant under my review ("How this was developed"
below). So I am asking those who know this code for a careful reading of
the fixes themselves. Most of them have a reproducer and were measured
in VMs, which says that the symptom goes away, not that the fix is the
one you would have written.

Of the twenty fixes, two take the kernel down: a divide by zero in
__dl_sub(), reachable from a debugfs write to a fair server while its
CPU goes offline or comes online, and a BUG() in the rebuild of the
accounting for a task whose isolated CPUs all went offline. Two leave
cpuset_mutex in a state that no deadline task can be admitted after: a
double unlock, and sysrq-n sleeping under tasklist_lock and keeping the
mutex. Three break the enforcement of a reservation: a throttled task
switched out of the class and back is left throttled with nothing to
replenish it, a task that comes back after its 0-lag time runs on the
deadline and runtime of the reservation it gave back, and a task whose
replenishment timer stays armed from that reservation is replenished at
a time of it. The other thirteen leave a root domain's total_bw, or a
runqueue's this_bw, holding what its tasks do not: the root domain then
admits deadline tasks beyond the capacity of its CPUs, or refuses every
one of them and refuses to offline its last CPU, and on the runqueue
side the kernel warns of the underflow.

The fixes, by patch number
==========================

 1  the policy check of __sched_setscheduler() retries without clearing
    the flag that says it holds cpuset_mutex, so the exit path unlocks
    a cpuset_mutex that is someone else's by then (Andrea Parri).
 2  sched_setattr() with SCHED_FLAG_KEEP_PARAMS carries out by half a
    request for another policy or another class: a class change runs
    switched_from_dl() on a task that stays in the class, and a request
    for SCHED_DEADLINE on a task that priority inheritance boosted into
    the class is admitted, reserving bandwidth the task never gets nor
    releases. Refused, before the reservation.
 3  the same flag has the parameters read from the task with no lock
    held: a change of its own that lands in between leaves the request
    stale, and the admission moves total_bw and the runqueue's sums to a
    bandwidth the task does not have. Nothing is to be admitted for
    parameters that are kept.
 4  __dl_sub() and __dl_add() divide a change of total_bw by the number
    of active CPUs of the root domain, which is 0 while a CPU passes
    through the default one; the debugfs write that reaches it is
    refused while the CPU is inactive, as it is once offline.
 5  __sched_setscheduler() takes cpuset_mutex for a deadline policy and
    releases it only with pi set: normalize_rt_tasks() takes it under
    tasklist_lock and keeps it. Taken only with pi, as before v6.5.
 6  a throttled task switched out of SCHED_DEADLINE and back before its
    0-lag time is left throttled with nothing to replenish it: it never
    runs again, and a fatal signal cannot make it run.
 7  __dl_clear_params() leaves the deadline and the runtime of the
    period a task left: back after its 0-lag time and before that
    deadline, it runs on the reservation it gave back.
 8  a task that leaves the class asleep, no inactive timer pending,
    keeps its bandwidth in total_bw for good. Released there, with the
    state of its period; the parameters stay for a boosted owner that
    may still read them.
 9  sched_setattr(SCHED_DEADLINE) on a zombie reserves bandwidth nothing
    releases, and a zombie of the class switched out of it is taken off
    its cpuset's count of deadline tasks a second time, after which a
    rebuild skips the cpuset. Both refused with ESRCH.
 10 a rebuild of the root domains' accounting (any cpuset partition
    change, CPU hotplug) forgets the bandwidth of the tasks that left
    the class, or died, before their 0-lag time: the inactive timer then
    removes it a second time, or from a root domain that never had it.
 11 a task whose wakeup is left to the target CPU has its bandwidth on
    no runqueue while task_cpu() already points at the destination: a
    parameter change meanwhile takes it off a runqueue that never held
    it, and this_bw underflows there for good.
 12 dl_rebuild_rd_accounting() is a stub without CONFIG_CPUSETS, so such
    a kernel loses the bandwidth of every deadline task at the first
    hotplug. A rebuild has nothing to serialize it against admission
    there either, where cpuset_mutex does not exist: a mutex of the
    deadline code's own, held from the attachment of the new root
    domains to the rebuild, as cpuset_mutex is.
 13 the walks of a rebuild can find a task at its last schedule, between
    the release of its bandwidth and the reset of its dl_bw, and count
    in a root domain just cleared a bandwidth nothing releases again.
 14 three answers live side by side to "which root domain counts this
    task's bandwidth": the one of the CPU the task is on (admission, a
    release), the one of the runqueue it is on (a move) and the one of
    its cpuset (a rebuild). They part ways where a sleeping task is
    moved or a CPU goes offline, and the bandwidth is then taken from a
    root domain that never had it. Every site that hands it out records
    a CPU of the root domain that counts it, and every site that takes
    it back or moves it reads that.
 15 a move takes a task's bandwidth off the root domain that counts it
    whenever the new mask leaves that root domain, on the strength of
    room nothing checks was made: a task that became a deadline task
    after cpuset_can_attach() counted them, and sched_setaffinity()
    with admission control off, have the room of no one. total_bw of a
    one-CPU partition root reaches 2^64 - 262144 that way.
 16 a rebuild of the sched domains from the sched_rt_runtime_us sysctl
    or the energy model runs between cpuset_can_attach() and
    cpuset_attach(), where the former's reservation is gone and the
    move goes through on its strength. The rebuild waits for the attach,
    as the writes of a cpuset's files do.
 17 what cpuset_can_attach() set aside for a task that left the class,
    or died, before the attach stays in the destination's total_bw: 200
    moves of a task that flips its policy leave hundreds of thousands
    of units of a CPU behind. The tally of what the attach moved comes
    from the move itself, under the runqueue lock that decides it.
 18 a rebuild of the accounting takes the first active CPU of a task's
    cpuset, which is an isolated one of the default root domain where
    the cpuset holds both, is none for a task whose isolated CPUs all
    went offline, which BUG()s, and is not where
    dl_task_offline_migration() moved a task. It takes the CPU recorded
    with the bandwidth where the cpuset still allows it, and a
    housekeeping CPU of the cpuset's otherwise.
 19 the replenishment timer of a task throttled before the end of its
    period stays armed where the task leaves the class and its
    parameters are cleared at its 0-lag time: back in the class, its
    next throttle does not reprogram that timer, and the replenishment
    comes at the period of the reservation it left.
 20 the runqueue a sleeping task is on counts none of the bandwidth the
    task gains where priority inheritance boosted it into the class:
    this_bw is then short of what running_bw takes at the wake-up,
    which the kernel warns about, and GRUB reclaims from sums that
    disagree.

Patch 21 gives sched_debug each runqueue's this_bw and running_bw, which
is what makes patch 11's bug visible from userspace, and patches 22 to
24 carry the selftests, 52 cases in three programs, in a directory of
their own, tools/testing/selftests/sched/deadline, as Juri suggested.

Patches 14 to 18 go together: 14 records the root domain that counts a
task's bandwidth, 15 and 17 are the two ways a cgroup attach moves or
strands bandwidth that record then exposes, 16 the rebuild that runs
through an attach, and 18 what a rebuild does with the record. Patch 14
comes after patch 10 because it rests on its list and generation. Patch
20 completes patch 11: where 11 left the bandwidth of a task waking
elsewhere to the enqueue to come, 20 hands it to the runqueue the task
will wake on.

Testing
=======

In 8 QEMU guests of 8 vCPUs, the 52 cases pass on the series, every
time. No case fails on 4 vCPUs either, with PREEMPT_RT, with
CONFIG_SCHED_PROXY_EXEC on and off, or on a kernel built without
CONFIG_CPUSETS, where the cases that want a cpuset partition root skip.
No kernel warning in any run, in 16 guests over those five
configurations, lockdep on in every kernel.

On v7.4-rc1, the same binaries fail ten cases of deadline_bw_test
(pi_former_owner_asleep, params_keep_class_change, params_keep_boosted,
move_asleep, move_non_contending, move_vs_rebuild,
death_zombie_switched, overrun_caught, random_mix and hotplug_departed),
the three of deadline_rebuild_test and the three of
deadline_switch_test, in 4 guests of 4, with kernel warnings in each;
params_waking skips for want of the sched_debug sums.
Built without cpusets, v7.4-rc1 fails hotplug_sleepers,
hotplug_departed and hotplug_server_refused, and skips the two other
hotplug cases for want of room, which patch 12 fixes.

One kernel per patch where a message claims one: the two round trips of
deadline_switch_test pass from patch 8 on, the three cases of
deadline_rebuild_test fail up to patch 9 and pass from patch 10,
move_vs_rebuild fails in 4 guests of 4 at patch 15 and passes at 16,
and the moves of cs_race leave bandwidth behind in 4 guests of 10 up to
patch 16 and in none of 6 at 17.

The eight standalone reproducers of v2 (the divide by zero, the mask
with no active CPU, the KEEP_PARAMS leak, the donor window, the cpuset
move race, the root domain of a departed task, the boosted task's
this_bw and the double unlock) pass on the series in 6 guests of 6. On
v7.4-rc1: the KEEP_PARAMS leak is 419424 -> 838854 of total_bw at one
call, the move race wraps a partition's total_bw to 2^64 - 262144 in
200 moves, the departed task leaves 104857 behind in the root domain it
left (471853 where 366996 is due), the double unlock reports "bad
unlock balance detected!", and the divide by zero oopses on the first
round; the mask with no active CPU is a bug of the dropped fixes, and
v7.4-rc1 survives it.

How this was developed
======================

These patches, their messages and the tests were written by an LLM
coding assistant under my direction and review.

It started from the cgroup selftests of a feature I am developing, which
the assistant also wrote: one of them hung about once in 1350 runs, and
another failed about once in ten. Asking it to root-cause those two
flakes, rather than work around them, gave patches 6 and 10. Reviewing
your four fixes of sched/urgent with it, Juri, gave patches 2 and 8. I
then asked for a selftest of the bandwidth accounting in its own right,
and for one area of coverage at a time: priority inheritance, parameter
changes, cpuset moves, deaths, sched_yield(), runtime overruns, GRUB
reclaiming, the fair servers, CPU hotplug, proxy execution, and a
randomized mix of all of them. That is deadline_bw_test, and building it
turned up patch 11, through the kernel's own this_bw underflow warning
under a parameter-change load, and patch 12, on a build without
cpusets. Patch 4 came from reading the code instead; its reproducer was
written afterwards, and takes an unfixed kernel down on the first round.
Patches 15 and 17 came out of the randomized case failing on its own
terms, which is what I wanted that case for.

Reviews of v1 and v2 by Sashiko AI, and of the reworks by a second
model, gave the rest, each finding checked against the code before
anything was written; the ones that were already answered by a later
patch of the series were answered, not fixed twice. The assistant got
things wrong on the way as well: one diagnosis of patch 11's bug was
wrong twice over and was settled only by instrumenting a kernel; one
assertion it had put in a test was itself racy and had to go; the first
shape of patch 14 wrote a flag under one lock that the runqueue lock
writes beside, which failed 14 VMs of 16 and is why patch 11 looks as
it does; and the first two shapes of the move_vs_rebuild case measured
the wrong thing and then raced nothing, until the moved process got
enough threads for a rebuild to land between the two cpuset callbacks.

Changes since v2
================

The base is v7.4-rc1, where tip sched/urgent is now, without the four
fixes v2 was built on; what became of each is at the top, and Andrea
Parri's fix is patch 1. Juri's Reviewed-by on v2's patches 1 and 2
carries over to patch 2, which merges the two with his 3/4, and to
patch 3.

From the Sashiko AI review of v2 (17 findings) and Juri's replies, each
checked against the code first:

 - patch 4 refuses the debugfs write of a fair server while its CPU is
   inactive, as Juri asked, rather than let it reach __dl_sub() with no
   CPU to spread the change over; the guard stays for the paths that
   have no write to refuse;
 - patch 5 (new): sysrq-n leaves cpuset_mutex locked for good, found
   from the review of patch 12's lock, and a baseline bug since v6.5;
 - patch 7 (new): the deadline and the runtime of the period a task
   left survive __dl_clear_params(), so a return before that deadline
   runs on the reservation it gave back, which patch 6 made a period
   wide. Juri read it as a bounded overrun to handle separately; the
   fix is two lines, so it is here;
 - patch 8 clears the state of the period with the bandwidth it
   releases, the throttle, the yield, the flags, the deadline and the
   runtime, and keeps the three parameters the donor window needs;
 - patch 9 (Juri's 4/4) also refuses to switch an exited task of the
   class to another policy, which ran switched_from_dl() and took it
   off its cpuset's count of deadline tasks a second time;
 - patch 12 takes its mutex in partition_sched_domains(), from the
   attachment of the new root domains, where dl_rebuild_rd_accounting()
   took it too late for an admission racing it;
 - patch 13 (new): both walks of a rebuild can find a task at its last
   schedule, between its release and the reset of its dl_bw, and leak
   what they count;
 - patch 14 refreshes three comments and gives no record to a boosted
   task with no bandwidth of its own;
 - patch 15 takes SCA_ bit 0x20: Andrea Parri's "sched/deadline: Check
   SCHED_DEADLINE affinity under the rq lock" takes 0x10;
 - patch 16 (new): a rebuild from the sched_rt_runtime_us sysctl or the
   energy model runs through an attach, between cpuset_can_attach() and
   cpuset_attach();
 - patch 18 is reworked around the record: the housekeeping filter of
   v2 lagged a cpuset partition change and stripped the isolated CPUs
   of a task whose affinity also named an offline housekeeping CPU, and
   the early return dropped a task that dl_task_offline_migration() had
   moved. A rebuild now credits the CPU recorded with the bandwidth
   where the cpuset still allows it;
 - patch 19 cancels the replenishment timer where patch 8 releases as
   well;
 - patch 20 tests the flags of the request rather than the entity's
   old ones, so a sugov kthread given a reservation of its own gets it
   counted;
 - v2's patch 5, the fallback for a mask with no active CPU, is gone
   with the fix it fixed; v2's patch 19 is Andrea's, patch 1 here.

Findings answered without a change: a departed task boosted into the
class is counted conservatively across a rebuild and never twice, and
the deboost racing the walk drops its departing bandwidth for the
remaining lag as an inactive CPU does; the parameters a task keeps after
leaving asleep were kept by the baseline on this path too, and what is
left of their effect is a lag warning at the next boost, which a
follow-up should clear once the chain walk is done; the EPERM on a
sleeping task moved to another partition is the baseline's affinity
check; and the server write while the CPU is inactive is what patch 4
refuses.

In the selftests: a directory of their own, sched/deadline, as Juri
suggested, and three cases: death_zombie_switched (patch 9),
move_vs_rebuild (patch 16) and sysrq_normalize (patch 5), the last
gated on DEADLINE_TEST_SYSRQ=1 since it renices every real-time task of
the system.

Based on v7.4-rc1, 6628e7d4c6b2, where tip sched/urgent is now.

Andrea Parri (1):
  sched: Fix cpuset_mutex double unlock in __sched_setscheduler()

Juri Lelli (1):
  sched/deadline: Reject SCHED_DEADLINE on exited tasks

Mathieu Desnoyers (22):
  sched: Refuse SCHED_FLAG_KEEP_PARAMS that would change the policy or
    the class
  sched/deadline: Do not admit bandwidth for parameters that are kept
  sched/deadline: Do not divide by zero active CPUs of a root domain
  sched: Take cpuset_mutex for a deadline policy change only with pi
  sched/deadline: Do not lose a throttled task switched out and back
  sched/deadline: Reset the deadline and the runtime with the parameters
  sched/deadline: Release the bandwidth of a task that leaves the class
    asleep
  sched/deadline: Keep departing bandwidth across a root domain rebuild
  sched/deadline: Do not take a waking task's bandwidth off a runqueue
    it left
  sched/deadline: Rebuild the root domains' accounting without cpusets
    too
  sched/deadline: Leave a dying task out of a rebuild of the accounting
  sched/deadline: Record the root domain holding a task's bandwidth
  sched/deadline: Move a task's bandwidth only where room was made
  cgroup/cpuset: Wait for an attach before rebuilding the sched domains
  cgroup/cpuset: Give back the bandwidth an attach did not move
  sched/deadline: Credit a rebuild to the CPU recorded with the task's
    bandwidth
  sched/deadline: Cancel the replenishment timer with the parameters
  sched/deadline: Count the bandwidth a boosted task is given
  sched/debug: Show the deadline bandwidth of each runqueue
  selftests/sched: Add a test of SCHED_DEADLINE policy round trips
  selftests/sched: Test SCHED_DEADLINE bandwidth across a root domain
    rebuild
  selftests/sched: Add a test of SCHED_DEADLINE bandwidth accounting

 include/linux/cpuset.h                        |    5 -
 include/linux/sched.h                         |   22 +
 include/linux/sched/deadline.h                |   21 +-
 kernel/cgroup/cpuset-internal.h               |    2 +
 kernel/cgroup/cpuset.c                        |   59 +-
 kernel/sched/core.c                           |   19 +
 kernel/sched/deadline.c                       |  644 ++-
 kernel/sched/debug.c                          |    9 +-
 kernel/sched/sched.h                          |    4 +
 kernel/sched/syscalls.c                       |   78 +-
 kernel/sched/topology.c                       |    9 +
 tools/testing/selftests/Makefile              |    1 +
 .../selftests/sched/deadline/.gitignore       |    3 +
 .../testing/selftests/sched/deadline/Makefile |    8 +
 tools/testing/selftests/sched/deadline/config |    5 +
 .../sched/deadline/deadline_bw_test.c         | 3564 +++++++++++++++++
 .../sched/deadline/deadline_rebuild_test.c    |  462 +++
 .../sched/deadline/deadline_switch_test.c     |  425 ++
 .../testing/selftests/sched/deadline/settings |    1 +
 19 files changed, 5218 insertions(+), 123 deletions(-)
 create mode 100644 tools/testing/selftests/sched/deadline/.gitignore
 create mode 100644 tools/testing/selftests/sched/deadline/Makefile
 create mode 100644 tools/testing/selftests/sched/deadline/config
 create mode 100644 tools/testing/selftests/sched/deadline/deadline_bw_test.c
 create mode 100644 tools/testing/selftests/sched/deadline/deadline_rebuild_test.c
 create mode 100644 tools/testing/selftests/sched/deadline/deadline_switch_test.c
 create mode 100644 tools/testing/selftests/sched/deadline/settings

-- 
2.47.3


^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2026-11-05 21:20 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-05 19:33 [PATCH v3 00/24] sched/deadline: bandwidth accounting fixes and selftests Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 01/24] sched: Fix cpuset_mutex double unlock in __sched_setscheduler() Mathieu Desnoyers
2026-11-05 19:51   ` Kayra Cizmeci
2026-11-05 19:54     ` Mathieu Desnoyers
2026-11-05 19:59       ` Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 02/24] sched: Refuse SCHED_FLAG_KEEP_PARAMS that would change the policy or the class Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 03/24] sched/deadline: Do not admit bandwidth for parameters that are kept Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 04/24] sched/deadline: Do not divide by zero active CPUs of a root domain Mathieu Desnoyers
2026-11-05 19:59   ` sashiko-bot
2026-11-05 19:33 ` [PATCH v3 05/24] sched: Take cpuset_mutex for a deadline policy change only with pi Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 06/24] sched/deadline: Do not lose a throttled task switched out and back Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 07/24] sched/deadline: Reset the deadline and the runtime with the parameters Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 08/24] sched/deadline: Release the bandwidth of a task that leaves the class asleep Mathieu Desnoyers
2026-11-05 20:10   ` sashiko-bot
2026-11-05 19:33 ` [PATCH v3 09/24] sched/deadline: Reject SCHED_DEADLINE on exited tasks Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 10/24] sched/deadline: Keep departing bandwidth across a root domain rebuild Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 11/24] sched/deadline: Do not take a waking task's bandwidth off a runqueue it left Mathieu Desnoyers
2026-11-05 20:35   ` sashiko-bot
2026-11-05 19:33 ` [PATCH v3 12/24] sched/deadline: Rebuild the root domains' accounting without cpusets too Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 13/24] sched/deadline: Leave a dying task out of a rebuild of the accounting Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 14/24] sched/deadline: Record the root domain holding a task's bandwidth Mathieu Desnoyers
2026-11-05 20:50   ` sashiko-bot
2026-11-05 19:33 ` [PATCH v3 15/24] sched/deadline: Move a task's bandwidth only where room was made Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 16/24] cgroup/cpuset: Wait for an attach before rebuilding the sched domains Mathieu Desnoyers
2026-11-05 20:36   ` sashiko-bot
2026-11-05 19:33 ` [PATCH v3 17/24] cgroup/cpuset: Give back the bandwidth an attach did not move Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 18/24] sched/deadline: Credit a rebuild to the CPU recorded with the task's bandwidth Mathieu Desnoyers
2026-11-05 20:58   ` sashiko-bot
2026-11-05 19:33 ` [PATCH v3 19/24] sched/deadline: Cancel the replenishment timer with the parameters Mathieu Desnoyers
2026-11-05 21:05   ` sashiko-bot
2026-11-05 19:33 ` [PATCH v3 20/24] sched/deadline: Count the bandwidth a boosted task is given Mathieu Desnoyers
2026-11-05 21:13   ` sashiko-bot
2026-11-05 19:33 ` [PATCH v3 21/24] sched/debug: Show the deadline bandwidth of each runqueue Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 22/24] selftests/sched: Add a test of SCHED_DEADLINE policy round trips Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 23/24] selftests/sched: Test SCHED_DEADLINE bandwidth across a root domain rebuild Mathieu Desnoyers
2026-11-05 19:33 ` [PATCH v3 24/24] selftests/sched: Add a test of SCHED_DEADLINE bandwidth accounting Mathieu Desnoyers
2026-11-05 21:17   ` sashiko-bot
2026-11-05 21:20 ` [PATCH v3 00/24] sched/deadline: bandwidth accounting fixes and selftests Mathieu Desnoyers

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®