On 30.04.26 14:09, Daniel Wagner wrote: > On Wed, Apr 29, 2026 at 11:01:33PM +0200, Florian Bezdeka wrote: >>> Which use case are you actually aiming to support? While dynamic >>> reconfiguration would be ideal, the amount of work to get there is >>> significant. I won't be signing up for it. >> >> The use case at hand is a RT enabled platform where the concrete RT >> workload is not known at boot time. RT applications are deployed "on- >> the-fly", nowadays using the existing container runtimes with some >> extended resource management on top. >> >> Applications can request certain resources like isolated CPU cores, >> special IRQ affinities, PCI devices to pass through, ..., so that the >> resource management on the system can take care of proper system >> configuration. > > > This is where I really question this use case. Currently, it takes quite > a lot of time to tune a system to work properly for RT workloads. > Between memory channel interference, GPU interference, and shared > transports everywhere, you end up with a fixed split: a set of CPUs > suitable for RT work and a set for housekeeping. This partitioning > generally does not change during runtime, even if the way you utilize > those two sets remains dynamic. > > Furthermore, reconfiguring a system while running an active RT workload > is asking for trouble. I wouldn't be surprised if doing so triggered a > wide range of unpredictable side effects.
No questions that the devils are waiting in the details (and some already showed up). It is a process of resolving issues and opening up use cases from "boring", restricting boot-time settings to more and more flexible reconfigurations. But if you do not hold up that goal and keep it in mind or even act accordingly on changes, you will never reached. Also RT would not be in mainline today without such a vision. Jan -- Siemens AG, Foundational Technologies Linux Expert Center
