20 Years Later, Real-Time Linux Makes It To the Kernel (zdnet.com)
- Reference: 0175035125
- News link: https://linux.slashdot.org/story/24/09/18/2151240/20-years-later-real-time-linux-makes-it-to-the-kernel
- Source link: https://www.zdnet.com/article/20-years-later-real-time-linux-makes-it-to-the-kernel-really/
> After 20 years, [1]Real-Time Linux (PREEMPT_RT) is [2]finally -- finally -- in the mainline kernel . Linus Torvalds blessed the code while he was at [3]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 [4]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.
[1] https://wiki.linuxfoundation.org/realtime/start
[2] https://www.zdnet.com/article/20-years-later-real-time-linux-makes-it-to-the-kernel-really/
[3] https://events.linuxfoundation.org/open-source-summit-europe/
[4] https://www.kernel.org/doc/html/next/core-api/printk-basics.html
This is a big deal (Score:2, Funny)
This shouldn't be a big deal, but it's a big deal because it shouldn't have been a big deal.
Important technical achievement (Score:2)
This is an amazing technical achievement.
Wonder if this really could have been sooner... (Score:2)
The article suggests that print_k was this major blocker to getting all the changes in. I don't know if that was the case, I'd hate to think that all this work was held up because somebody wanted to printf debug the kernel like it was the 90s.
Then again, it could have been just a reasonable milestone on a long list of stuff. Either way, well done to the team.
Could be a big boost to audio applications on the kernel. It is very useful to have features like "hey, make sure this grabs a buffer every so and so.
Will it get real-world commercial use? (Score:4, Insightful)
If I was manufacturing something mission critical that needed a RTOS I'd probably go with QNX due to it's proven track record and micro kernel architecture. I wouldn't go for something that is tacked onto a monolithic kernel, and one that not all kernel developers seem to care about.
I think that if a feature has no users then it shouldn't be in the kernel. Maybe in 10 years they'll go, "Yeah OK no one ended up using this feature. It's a pain to maintain. It's now marked as depreciated and we will remove it sometime in the future". I think that is the elephant in the room here. That is - is this something people will actually use, or is it a pointless academic exercise?
Re: (Score:2)
is this something people will actually use, or is it a pointless academic exercise?
A more responsive GUI with little overhead sounds like one real world use case.
Re: Will it get real-world commercial use? (Score:2)
The goal of an RTOS is not to make things faster -> "more responsive". It's to make things predictable with a deterministic max response latency.
I could benefits in being able to run and debug RT workloads within your desktop... but treating your UX as an RT program and erroring on microsecond sounds like a lot more work for a much worse experience
Re:Will it get real-world commercial use? (Score:4, Informative)
It's been used for years in CNC machine control. Glad to see it in the mainline tree now. Makes life a lot easier for those running LinuxCNC or MachineKit. MachineKit seems to have evolved far beyond CNC and can be used in any situation where you need real-time control over machinery like stepper motors, industrial machines, etc.
It's not something normal users will ever use, and I don't think it is helpful for a desktop GUI. In fact it might slow down a GUI due to the harder scheduling requirements.
So anyway yes this is something people actually use. It's not academic at all.
Re: (Score:3)
Yes, a European car consortium is already building vehicles around it.
IIRC there was an article here a few months ago.
Brakes gotta brake.
Re: (Score:2)
It is already in very wide use in many Embedded Linux systems. Yes it's very practical. But probably not on a PC, a PC is a boring platform because they solve all problems by just waiting for faster hardware.
And the Linux kernel has a lot of tasks now, it's not at all the same as early Linux monolithic kernels. But the kernel vs userspace architecture often means some real time activities end up being modules hooked into the kernel. At the same time, with threaded processes the real time can apply even
BeOS (Score:2)
Around 25 years ago I was writing for a company developing a multitrack recording system using BeOS. Man, BeOS was snappy; it was designed to be a media (audio and video) OS. In many ways it was better than Linux as an alternate OS to Macs and Windows, but Linux won.
But in 1998, when you clicked on a background BeOS window, it immediately jumped to the front, and if you clicked a button you got immediate visual feedback, even if the action might take longer to carry out. How come this was not implemented el
Jesus christ (Score:2)
Linux RTOS patches existed way back in 2.2-2.4 releases, if memory serves. Torvalds wouldn't let it merge for 24 years because of his precious function? What a dick
SO stupid it took this long (Score:2)
It's so stupid it took this long for realtime Linux kernel to hit the main kernel because a certain prima donna wanted to protect his 33-year-old debugging tool.
Could there be desktop linux benefits? (Score:2)
"could" because I know this mostly benefits embedded stuff
Re:Could there be desktop linux benefits? (Score:4, Interesting)
Audio production comes to mind.
Re: (Score:2)
Not really. RTOS is important when you're dealing with potentially expensive interactions in the physical world - you can't pause physics, and you can't magically replace destroyed raw materials.
For audio *production*, computers are already fast enough such that imperceptibly small latency builds in all the protection you need against starvation, even in high end production.
RTOS may be attractive for certain applications that *have* audio playback, say an immersive ride with motors that should act in sync w
Re: (Score:2)
Put in speakers loud enough and you want to have it ensured that there won't be gaps in the audio.
I suppose that's still really mostly relevant to live performances, though, and just having the lowest layer perform won't be enough. It's nice to have, but people have done without.
The lowest level could perhaps protect against loss of input stream by having a dynamically generated backup track to ensure sound continuity.
Re: (Score:2)
It might avoid an embarrassingly delayed boss key?
Re: (Score:2)
In theory yes for low latency multimedia and industrial uses, although don't quote me on that, but in practice modern desktop machines can achieve low latencies for audio simply by being fast as hell.
Re: Could there be desktop linux benefits? (Score:2)
If you do real-time right, it makes the system more stable. It sounds like they did a good job carefully looking at each area of the code and analyzing it, so it sounds like this will a make.the code more stable. Now we just need a real-time systemd written in Rust.
Re: (Score:3)
I've been using Debian/Devuan with parameter preempt=full in grub, and the usual desktop use feels just that bit more snappier.
Re: (Score:2)
I don't think that has anything to do with PREEMPT_RT, though. I don't think PREEMPT_RT would help a desktop GUI at all. But if you need accurate timing to control a signal through a GPIO pin, that's what PREEMPT_RT is for.
Re: (Score:2)
I don't think so. Since the purpose of RT is to provide precise and accurate timing guarantees to processes (for example toggling a GPIO pin to generate a signal), that might force GUI processes to wait, making it feel sluggish. I read once that a hard real-time system often can't utilize the entire capability of the CPU because of the real-time guarantees (this will run in X cycles, guaranteed). Whereas under normal linux, the scheduler can pre-empt other processes and even change their priority, which
Re: Could there be desktop linux benefits? (Score:1)
I'm wondering if this would be beneficial for emulators and VM environments too. TFA mentioned how some prior changes already made improvements in the data center.