The Printk Blocker For Upstreaming Real-Time "PREEMPT_RT" Has Been Merged

[phoronix]

Phoronix: The Printk Blocker For Upstreaming Real-Time "PREEMPT_RT" Has Been Merged

The printk changes to finish the NBCON consoles work has been merged for Linux 6.12! This is the last remaining blocker on real-time "PREEMPT_RT" support from being upstreamed. We're now tantalizing close to seeing the real-time kernel support merged after many years of being out-of-tree patches...

https://www.phoronix.com/news/Linux-6.12-Printk-Merged

[bug77]

I haven't followed this in a long while so correct me if I'm wrong: the Linux kernel is already soft real-time and these patches are about making it hard real-time. Right?

[EphemeralEft]

I feel like it’ll still be a few releases before RT is usable, and probably at least a year until anyone is willing to bet their life on it.

[bug77]

I feel like it’ll still be a few releases before RT is usable, and probably at least a year until anyone is willing to bet their life on it.

It's already usable (and in use), only as out-of-tree patches. It will just be easier to maintain from now on.

[uid313]

My Linux console have ugly colors. Also no mouse support.

[F.Ultra]

I haven't followed this in a long while so correct me if I'm wrong: the Linux kernel is already soft real-time and these patches are about making it hard real-time. Right?

No, the current Linux Kernel is not soft real-time, the PREEMPT_RT patchset is what will enable it to be soft real-time. Linux on par of being general-purpose can not be a hard real-time OS but with this patchset it can be both general-purpose and soft real-time which for most situations is good enough.

[jabl]

I haven't followed this in a long while so correct me if I'm wrong: the Linux kernel is already soft real-time and these patches are about making it hard real-time. Right?

Well, yes, and no. Problem is, there's no universally agreed upon definition on what constitutes a soft and hard real-time system, and what are the exact boundaries that distinguish between them. A somewhat common definition is that a hard real-time system is a system where failure to meet a deadline constitutes a system failure (e.g. someone dies or your $$$ space rocket crashes, or both), whereas a soft real-time system is able to carry on (say, your CNC machine destroyed a part it was machining which is hopefully a non-catastrophic economic loss to your company, but is able to continue making other parts).

Another definition to what is a hard real-time system is a system that is formally proven to always be able to meet its deadlines, and of course neither Linux nor any other general purpose OS can meet such a definition. But then the question is, what does "always" in the preceding sentence mean, exactly? If you take a hammer and smash the system to bits, it will miss its deadline, formally proven or not (ergo, what are the prerequisites or axioms going into the formal proof?). And how far down the rabbit hole do you require the formal proof to go? Does it include firmware? Or the hardware description itself? Does the actual hardware match the Verilog/VHDL/whatever?

And of course, what is the deadline we're trying to meet? If it's, say, one hour, yeah you don't need any fancy real-time OS for that. Or for the other extreme, demand low enough deadlines and you'll need something implemented straight in HW without any OS with interrupts and whatever to serve.

So what is the point of the above? I don't know, except maybe don't trust people with very strong opinions, unless they very clearly specify what exactly they mean. As for Linux, well CONFIG_PREEMPT makes it more 'real-timeish' than with a non-preemptible kernel configuration. CONFIG_PREEMPT_RT makes it even 'more real-time' than CONFIG_PREEMPT. But is it soft or hard real-time, depends on how exactly you want to define it.

[Veto]

So what is the point of the above? I don't know, except maybe don't trust people with very strong opinions, unless they very clearly specify what exactly they mean. As for Linux, well CONFIG_PREEMPT makes it more 'real-timeish' than with a non-preemptible kernel configuration. CONFIG_PREEMPT_RT makes it even 'more real-time' than CONFIG_PREEMPT. But is it soft or hard real-time, depends on how exactly you want to define it.

Wise words! However, it would be nice with some quantification of the real-time behaviour of CONFIG_PREEMPT and CONFIG_PREEMPT_RT.

[fong38]

How well would soft RT benefit high stressing desktop scenarios? For instance when I run I/O heavy tasks like deduplication (using duperemove) on my BTRFS partition I get severe desktop and audio stutter. Would this be of help here?

[ehansin]

No, the current Linux Kernel is not soft real-time, the PREEMPT_RT patchset is what will enable it to be soft real-time. Linux on par of being general-purpose can not be a hard real-time OS but with this patchset it can be both general-purpose and soft real-time which for most situations is good enough.

Some day I'd like to do "just for fun" audio recording and music creation stuff with Linux. I remember many years ago there being custom kernels for such things, but do not remember the details (may have been some of the PREEMPT patches applied.)

I think has been mentioned before, but I assume this would be advantageous for more "pro-level" audio work. If the answer is it is, and adding in PipeWire, I am guessing Linux could really be a top-notch platform for this kind of thing. Maybe already is, have not gotten too deep into it yet.