After 20 years, Real-Time Linux (PREEMPT_RT) is finally – finally – in the mainline kernel. Linus Torvalds blessed the code while he was at Open Source Summit Europe. […] The real-time Linux code is now baked into all Linux distros as of the forthcoming Linux 6.12 kernel. This means Linux will soon start appearing in more mission-critical devices and industrial hardware. But it took its sweet time getting here. An RTOS is a specialized operating system designed to handle time-critical tasks with precision and reliability. Unlike general-purpose operating systems like Windows or macOS, an RTOS is built to respond to events and process data within strict time constraints, often measured in milliseconds or microseconds. As Steven Rostedt, a prominent real-time Linux developer and Google engineer, put it, “Real-time is the fastest worst-case scenario.” He means that the essential characteristic of an RTOS is its deterministic behavior. An RTOS guarantees that critical tasks will be completed within specified deadlines. […]
So, why is Real-Time Linux only now completely blessed in the kernel? “We actually would not push something up unless we thought it was ready,” Rostedt explained. “Almost everything was usually rewritten at least three times before it went into mainline because we had such a high bar for what would go in.” In addition, the path to the mainline wasn’t just about technical challenges. Politics and perception also played a role. “In the beginning, we couldn’t even mention real-time,” Rostedt recalled. “Everyone said, ‘Oh, we don’t care about real-time.’” Another problem was money. For many years funding for real-time Linux was erratic. In 2015, the Linux Foundation established the Real-Time Linux (RTL) collaborative project to coordinate efforts around mainlining PREEMPT_RT.
The final hurdle for full integration was reworking the kernel’s print_k function, a critical debugging tool dating back to 1991. Torvalds was particularly protective of print_k --He wrote the original code and still uses it for debugging. However, print_k also puts a hard delay in a Linux program whenever it’s called. That kind of slowdown is unacceptable in real-time systems. Rostedt explained: “Print_k has a thousand hacks to handle a thousand different situations. Whenever we modified print_k to do something, it would break one of these cases. The thing about print_k that’s great about debugging is you can know exactly where you were when a process crashed. When I would be hammering the system really, really hard, and the latency was mostly around maybe 30 microseconds, and then suddenly it would jump to five milliseconds.” That delay was the print_k message. After much work, many heated discussions, and several rejected proposals, a compromise was reached earlier this year. Torvalds is happy, the real-time Linux developers are happy, print_K users are happy, and, at long last, real-time Linux is real.
Heck yeah. Now a microkernel version of Linux would be the icing on top!
I do understand why. Due to all the heated discussions with Rust in Linux, it does makes a lot of sense to rebuild a kernel in Rust from scratch. However, it will take a long time to get on the same level of Linux (read: 30+ years).
Definitely will take time, though let’s not discount the fact that Linux came about before the internet was the internet. I don’t know if it will take 30 years, but certainly ten years or more doesn’t seem unreasonable.
This is super interesting. I’ll admit I wasn’t even aware of this effort. Even real-time usage of Windows relies on a parallel kernel.
This sounds like it’ll create a lot of cool opportunities and reduce friction.
But the RT patches have been available for 20 years… not sure why the fact that it is mainlined would suddenly expand its popularity? It might be easier to get started sure, but people doing RT were already going to such troubles anyway.
It’s like saying GPS was available for decades before, why would putting it in everyone’s phone expand its popularity.
For myself, I’m hoping the nerds and hackers that otherwise found it not worth the effort will start creating tools to manage real time better and start building them into the applications they write. That way you don’t need to pay an arm and a leg to RedHawk for the privilege of dynamically isolating CPUs or have to reboot the computer to modify kernel arguments a la RedHat MRG.
I don’t think that comparison is fair because I explicitly said that people who wanted RT are already going out of their way to get things done. The average desktop user (putting GPS in every phone) won’t benefit from it (or RT) and it could likely make their experience even worse.
Intriguing. The first and last time I saw anything RT kernel related was nearly a decade ago, when I stumbled on it as an alternate kernel in the old synaptic package manager.
Music Makers will love this
I’m curious about this. I’ve started playing with Reaper and getting into music recording and production. I’m very fresh on the scene and haven’t used any DAWs on any other OS, except viewed protools on Mac. I can’t quite get latency free playback, which may just be user error and configs.
Do you know if something like this will have default benefits out of the box, or will we need to somehow configure our apps and services to utilize these changes? I’m completely ignorant but am really intrigued.
I have a relative who I helped set up RTLinux (?) on Kubuntu back in 2018. I think they were playing around with Helm, Calf, Ardour, Hydrogen, Rosegarden et all and JACK of course, but that’s all I remember on the music production side - I was helping more along the lines of PPAs, compiling and configuring and mostly on WE after I came back from somewhere, so 3AM or smth (not good for memory).
after much work, many heated discussions, and several rejected proposals, a compromise was reached earlier this year.
So what was the compromise with print_k??
Doesn’t say, but I am curious. They said their workarounds broke other workarounds which caused a lot of implementation delay, but I’m not sure what the actual compromise was to address all that.
Answer probably lies somewhere in the kernel maintainer’s mailing list, I’d imagine. Just not equipped to search for it right at the moment.
