this post was submitted on 19 Sep 2024

2 points (100.0% liked)

Linux

7076 readers

690 users here now

A community for everything relating to the GNU/Linux operating system

Also check out:

Original icon base courtesy of [email protected] and The GIMP

founded 2 years ago

MODERATORS

[email protected]

20 years later, real-time Linux makes it to the kernel - really (www.zdnet.com)

submitted 7 months ago by [email protected] to c/[email protected]

26 comments fedilink hide all child comments

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.

top 26 comments

sorted by: hot top controversial new old

[–] [email protected] 1 points 7 months ago (1 children)

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??

[–] [email protected] 0 points 7 months ago (1 children)

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.

[–] [email protected] 0 points 7 months ago (1 children)

Let's ask ChatGPT! ahhaah just kidding.. kidding..

[–] [email protected] -1 points 7 months ago (1 children)

😡

[–] [email protected] -1 points 7 months ago (2 children)

Look what I just did:

"In a real-time kernel, the trouble with using print_k (or similar logging functions) often revolves around potential disruptions to real-time performance. Here are some key issues:

Blocking Behavior: print_k may block if the output buffer is full, leading to unpredictable delays in real-time tasks.
Interrupt Context: Using logging functions within interrupt handlers can lead to priority inversion, causing lower-priority tasks to block higher-priority ones.
Latency: Printing can introduce significant latency, which is detrimental in real-time systems that require deterministic timing.
Context Switching: Frequent logging can increase context switching overhead, impacting overall system performance.
Overhead: The computational overhead of formatting and outputting strings can interfere with time-sensitive operations.

For these reasons, it’s typically recommended to use alternative methods, such as circular buffers for logging, or to minimize logging in real-time contexts.

[–] [email protected] 1 points 7 months ago

I got this back from ChatGPT (most likely false info!):

ChatGPT response (you have been warned)

The compromise for integrating PREEMPT_RT into the Linux mainline kernel, including the handling of printk, required several changes and concessions over time. These compromises made it possible to finally integrate real-time (RT) capabilities while maintaining the overall philosophy and structure of the Linux kernel. Key Compromises Made:

Soft-Real-Time Focus:

One of the biggest compromises was accepting that Linux would focus on soft real-time capabilities instead of hard real-time guarantees. This was crucial for widespread acceptance in the mainline kernel, as hard real-time guarantees were too difficult to meet without significant changes that would have disrupted the kernel's general-purpose use cases. PREEMPT_RT was designed to offer deterministic behavior with reduced latencies, but it doesn't provide the strict guarantees of traditional hard real-time systems like VxWorks or QNX.
printk Latency Handling:

Non-blocking printk: One compromise involved updating printk to avoid long blocking during logging operations. It was changed to be more asynchronous, reducing the impact on real-time scheduling. Deferred printing: Another approach was to defer the actual printing of log messages to avoid introducing large latencies in time-critical paths. The goal was to prevent printk from stalling critical tasks, especially those with real-time priority.
Voluntary Preemption Points:

Voluntary preemption was introduced, allowing kernel code paths to insert preemption points that allow the scheduler to preempt running tasks, improving latency. However, this does not guarantee immediate preemption, which is another compromise compared to true hard real-time systems. These preemption points had to be carefully placed to balance performance and responsiveness without destabilizing the general-purpose kernel.
Threaded Interrupts:

Another significant compromise was the conversion of hard IRQs (interrupts) into threaded interrupts. While this allows real-time tasks to take precedence over hardware interrupts (which would traditionally have a higher priority), it involves some overhead and performance trade-offs. Not all interrupts could be threaded easily, and this change required reworking many drivers to ensure that they were compatible with threaded interrupts.
Preemptible Spinlocks:

Spinlocks in the kernel traditionally prevent preemption. To enable real-time preemption, spinlocks were made preemptible, allowing real-time tasks to preempt even code holding spinlocks. This change wasn't trivial, as it involved significant reworking of kernel locking mechanisms to ensure the system remained stable and avoided deadlocks, without degrading performance in non-real-time scenarios.

[–] [email protected] 0 points 7 months ago (1 children)

This is exactly the information I already had before based purely off the name print_k

[–] [email protected] 1 points 7 months ago

And is this already where it goes wrong with people trying to use "AI"..

[–] [email protected] 1 points 7 months ago (1 children)

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.

[–] [email protected] 1 points 7 months ago (1 children)

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.

[–] [email protected] 0 points 7 months ago (1 children)

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.

[–] [email protected] 0 points 7 months ago (1 children)

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.

[–] [email protected] -1 points 7 months ago (1 children)

People who wanted GPS were also already using it by buying TomToms or other GPS devices…

The average desktop user already benefits from the changes the RT folks have slowly been getting into the baseline.

[–] [email protected] 0 points 7 months ago (2 children)

People who want RT are not everyday people though.

How does an average desktop user benefit from any RT changes?

[–] [email protected] 1 points 7 months ago

You seem to have the idea that there are "people who want RT" and they'll overcome any inconvenience to get it, therefore making RT more convenient to use won't increase use of it.

Clearly nonsense, and I think the GPS analogy is a good one. My mum isn't "a person who wants GPS" and she would never have bought a GPS device in the 00s, but she uses one now because it's conveniently already available in her phone.

[–] [email protected] -1 points 7 months ago

The most obvious answer is gaming. Hard 60/144Hz deadlines is RT. But there are lots of changes that got into the kernel from the RT group, starting with getting rid of the BKL, which helped everyone.

[–] [email protected] 1 points 7 months ago

after using gentoo for a couple months, i think i know a thing or two about spending Real Time getting the linux kernel

[–] [email protected] 1 points 7 months ago (1 children)

Heck yeah. Now a microkernel version of Linux would be the icing on top!

[–] [email protected] 1 points 7 months ago

RedoxOS is trying to do that with Rust

[–] [email protected] 1 points 7 months ago

Music Makers will love this

[–] [email protected] 0 points 7 months ago (1 children)

Does this mean anything to the average user, or is this a very specific use case?

[–] [email protected] 1 points 7 months ago (1 children)

Probably some use cases for "regular" users. Someone mentioned music production, though that's probably more professional than hobby.

To my understanding, you mostly need real time performance for specialty cases where timing is absolutely critical. So I guess if you were building custom drones or custom control boards for drones, you could use real time Linux for that now since the timing could be guaranteed.

[–] [email protected] 0 points 7 months ago (1 children)

So what about 3D printing? Currently, input shaping uses an accelerometer to calculate resonances and uses that data to adjust movement and reduce flaws in the printing process. For anyone with knowledge of both fields, would this allow a built-in or add-on accelerometer to be used in real time to compensate for momentum and resonances even further?

[–] [email protected] -1 points 7 months ago (1 children)

What’s preventing that from working now? If it’s indeterminate latency, then yeah, absolutely. Theoretically this will give you the ability to have a very deterministic loop around the accelerometer data, but 3d printers don’t move all that fast to begin with so having unbounded latency might not matter. The determinism we’re talking about here is on the order of tens of microseconds or less.

[–] [email protected] 0 points 7 months ago (1 children)

3D printers can move very fast. They typically don't because it causes all kinds of deformations in the print. Mostly the issues are in acceleration, decelaration, cornering, and controlling the heat snd flow of melting filament.

I don't know whether or not the accelerometer thing can be done in real time, or if there would be any benefit.

Check out the 2-minute Benchy for an example of how fast a 3D printer can get. This is a test print that typically should take about 45 minutes to an hour at very basic settings.

But also note the quality of the end product. It looks pretty awful. If we could print accurately at even remotely similar speeds, it would be fantastic.

[–] [email protected] -1 points 7 months ago

“Very fast” is relative. 1200mm/s is very fast for 3D printing, no argument. But it’s 1.2mm/millisecond, and we’re talking about time scales in the microsecond range. I suspect you’re going to run into materials issues far before real time performance becomes a limiting factor in print speed and quality.