Re: [RFC PATCH v6 00/25] Hierarchical Constant Bandwidth Server

[Juri Lelli]

Hi Yuri,

On 08/06/26 14:15, Yuri Andriaccio wrote:
> Hello,
> 
> This is the v6 for Hierarchical Constant Bandwidth Server, aiming at replacing
> the current RT_GROUP_SCHED mechanism with something more robust and
> theoretically sound. The patchset has been presented at OSPM25 and OSPM26
> (https://retis.sssup.it/ospm-summit/), and a summary of its inner workings can
> be found at https://lwn.net/Articles/1021332/ . You can find the previous
> versions of this patchset at the bottom of the page, in particular version 1
> which talks in more detail what this patchset is all about and how it is
> implemented.
> 
> This v6 version works on the comments by the reviewers and introduces the
> following meaningful changes:
> - Update to kernel version 7.1.
> - Refactorings and general cleanups.
> - Removal of substantial duplicated code.
> - Express more locking constraints in code.
> - New cpu.rt.max interface.
> - Refactoring of migration code to reduce code duplication.
>   The new migration code now reuses the existing push/pull and similar functions
>   and specializes where needed, substantially reducing the footprint of group
>   migration code from previous versions.

I've been working on a simple demo and benchmark suite for HCBS to
explore real-world like use cases and characterize the feature's
behavior. Different angle wrt your unit test suite (I believe).

The demo is available at:

  https://github.com/jlelli/hcbs-demo

The demo models three scenarios — Industrial PLC Convergence, Robotics
Compute Platform, and Precision Motion Control — each with multiple
cooperating SCHED_FIFO tasks at different priorities sharing a cgroup,
which is the key differentiator vs. plain SCHED_DEADLINE. An aggressor
subsystem overloads the system while HCBS contains it to its budget.

A side-by-side compare mode runs baseline and HCBS simultaneously on
separate cpuset partitions, with a live terminal dashboard showing the
contrast in real time.

Key findings from testing on an Intel Xeon Gold 6433N (4 isolated CPUs
via cpuset partition):

 - At 10ms task periods, HCBS provides perfect temporal isolation: zero
   victim deadline misses across all scenarios, while aggressors are
   correctly throttled to their budget.

 - At 1ms task periods, the dl-server period is the critical tuning
   parameter, less the bandwidth. A 10ms dl-server with 60% bandwidth
   caused ~10% miss rates because the worst-case throttle gap (4ms)
   spanned multiple 1ms deadlines. Switching to a 2ms dl-server period
   at just 30% bandwidth eliminated all misses.

 - A simple Rule of thumb might be to set the dl-server period to at
   most 2x the shortest task period in the cgroup (e.g., 2ms dl-server
   for 1ms tasks, 10ms for 10ms tasks). Would you (and Luca?) agree or
   would you suggest something different?

 - dl-server overhead itself appears negligible: a parameter sweep
   confirmed zero misses for a single task at all bandwidth/period
   combinations tested.

 - The current v6 has been quite stable throughout my testing — no
   warnings, no crashes, and the bandwidth isolation works as expected
   across all the scenarios and workload combinations I've tried.

The demo supports three workload backends:
 - rt-app (default): synthetic periodic tasks with configurable periods
 - RT-Bench TACLeBench (--rtbench): real algorithms (susan, dijkstra,
   FFT, mpeg2, etc.) matching each scenario's computation profile
 - stress-ng (--stress): mixed CPU/IO/cache/memory aggressors for
   realistic interference patterns

Recorded demos (asciinema):
  Industrial: https://asciinema.org/a/5e4BMdWxS7hmm4hI
  Robotics:   https://asciinema.org/a/Msj48XnJGgcCev7M
  Precision:  https://asciinema.org/a/56WC3bu7yrcQe9nz

Thanks for the great work on this patchset. Happy to hear if this demo
is of any interest, discuss any of the findings and/or understand if/how
this can be further expanded.

Best,
Juri