Since 2004 a project has been going on trying to make the Linux kernel into a true hard Real-Time operating system. This project has become know as PREEMPT_RT (formally the "real-time patch"). Over the past decade, there was a running joke that this year PREEMPT_RT would be merged into the mainline kernel, but that has never happened. In actuality, it has been merged in pieces. Examples of what came from PREEMPT_RT include: mutexes, high resolution timers, lockdep, ftrace, RT scheduling, SCHED_DEADLINE, RCU_PREEMPT, generic interrupts, priority inheritance futexes, threaded interrupt handlers and more. The only thing left is turning spin_locks into mutexes, and that is now mature enough to make its way into mainline Linux. This year could possibly be the year PREEMPT_RT is merged!
Getting PREEMPT_RT into the kernel was a battle, but it is not the end of the war. Once PREEMPT_RT is in mainline, there's still much more work to be done. The RT developers have been so focused on getting RT into mainline, that little has been thought about what to do when it is finally merged. There is a lot to discuss about what to do after RT is in mainline. The game is not over yet.
POSIX condition variables (condvars) provide a commonly used interprocess communication mechanism. Threads can queue up and wait for an event before continuing. The glibc implementation of condvars in 2009 was not suitable for use in real-time systems due to a potential priority inversion. A fix has been available and used in many real-time systems since that time. A recent change to glibc to...
Xenomai offers a wonderful debugging feature: whenever a realtime thread calls an non-rt safe syscall, SIGXCPU is delivered. That is particular helpful for users which build their application on top of libraries. Often it is not clear what the side effects of a library call is.
What options are there to implement something similiar to SIGXCPU? A simple prototype using BPF showed the limits...
Julia has worked with an Extreme-Value-Analysis tool that can analyze a lot of data. Collecting various output runs of jitterdebug, which collects all jitter data (outliers and all), could it be useful to analyse the data that it produces?
The PREEMPT_RT's current metric, the latency is good. It helped to guide the
development of the preempt_rt for more than a decade. However, in real-time
analysis, the principal metric for the system the response time of tasks.
Generally, in addition to the latency, the response time of a task comprises the
task's execution time, the blocking time on locks, the overhead associated...
Lots of research has been made to various issues like CPU affinity, Bandwidth inheritance, cgroup support; but nothing has been done to the kernel. Let's make a commitment and push these ideas forward into mainline.
Setting RT Priority inside usernamespace is not allowed even for mapped root uid. The use case is to be able to run RT priority processes inside usernamespace. Should there be a way to allow this, subject to cgroup RT limits, if a cgroup is dedicated to the usernamespace?
Is there need to change anything how we maintain the stable-rt trees? Or should we focus all effort on supporting the mainline tree?
- Steven Rostedt
- Sebastian Andrzej Siewior
- Thomas Gleixner
- Tom Zanussi
- Julia Cartwright
The fully preemptive preemption model, along with real-time mutexes, are the main features of the PREEMPT RT.
How do we check if we are respecting all the rules for these features, e.g., how do we check if changes in the kernel are not breaking the preemption or the locking model?
For locking, we already have an answer: Lockdep!
But how about the preemption model?
The presenter has a...
Linux is playing very well in the case of embedded system, and could be good candidate to IoT. But talking about IoT, especially IIoT, Industrial IoT, we run those essential systems across critical infrastructures so we need to deliver responsive capabilities in real time. Meantime, the software needs to be certified by different standards or certifications.
So in this talk, I hope we can...