New Threaded/Atomic Console Patches Posted For Linux - Precursor For Mainlining RT

[phoronix]

Phoronix: New Threaded/Atomic Console Patches Posted For Linux - Precursor For Mainlining RT

Posted today was the "v1" patch series implementing threaded/atomic console infrastructure for printk. This is one of the last steps needed before the real-time (PREEMPT_RT) support can be finally mainlined into the Linux kernel...

https://www.phoronix.com/news/Printk-Threaded-Atomic-v1

[JEBjames]

Michael

Typo

"without waiting on colse printing" I'm assuming you meant "console"?

[Michael]

Michael

Typo

"without waiting on colse printing" I'm assuming you meant "console"?

Whoops, fixed. Thanks.

[caligula]

This is great news for all pro audio users who couldn't play back the highest quality streams (qobuz, tidal) without noticeable jitter and noise. Lower than 1ms latency becomes important when your playback equipment uses 384 kHz and 32 bits.

[Mitch]

Do other OSes like Windows and Mac use their own version of RT that kicks in for pro audio users? If not, why does Linux need RT more than other OSes for the same use case?

Not knocking anything anyone is doing. Just curious. I know RT Linux is a big deal in vehicle / equipment safety

[cj.wijtmans]

Do other OSes like Windows and Mac use their own version of RT that kicks in for pro audio users? If not, why does Linux need RT more than other OSes for the same use case?

Not knocking anything anyone is doing. Just curious. I know RT Linux is a big deal in vehicle / equipment safety

In windows api you can set thread to realtime.

[jabl]

In windows api you can set thread to realtime.

You can do that in Linux as well, even if you're running a regular (non-RT) kernel. See e.g. https://www.man7.org/linux/man-pages/man7/sched.7.html

[jabl]

Do other OSes like Windows and Mac use their own version of RT that kicks in for pro audio users?

I'm quite sure they don't have anything like that. AFAICS it's not really feasible to dynamically change the kernel from a "normal" to a fully preemptible RT kernel on the fly. And having the kernel fully preemptible "RT-capable" as default would have too much of a performance hit for the vast majority of use cases.

If not, why does Linux need RT more than other OSes for the same use case?

Does it? Well, one thing Windows can do is change the timer tick on the fly, whereas in Linux it's a compile-time constant (CONFIG_HZ). So some soft realtime applications can increase the scheduler tick rate, and maybe get shorter latencies that way. But that seems to have changed recently, see https://randomascii.wordpress.com/20...t-rule-change/

Anyway, I'm not familiar with the internals of Windows or macOS, but I'd guess they are both architecturally similar to a standard non-RT Linux kernel, except some things are just tuned and tweaked a little better so some soft real time applications like pro audio works well enough out of the box.

Not knocking anything anyone is doing. Just curious. I know RT Linux is a big deal in vehicle / equipment safety

I think RT Linux is really aimed for these kinds of industrial control systems etc. , but Windows and macOS are not really playing there so it's difficult to compare. Also the user space application architecture of such hard real time applications is somewhat different from normal applications, it's not just about the kernel.

[ayumu]

You can do that in Linux as well, even if you're running a regular (non-RT) kernel. See e.g. https://www.man7.org/linux/man-pages/man7/sched.7.html

Set it? Sure.

But the performance is abysmal, with latency spikes easily at tens of milliseconds. Cyclictest from rt-tests can easily demonstrate that.

For actual sane behavior (maxing at around ~100us), PREEMPT_RT is needed.

[jabl]

Set it? Sure.

But the performance is abysmal, with latency spikes easily at tens of milliseconds. Cyclictest from rt-tests can easily demonstrate that.

My point exactly. Existence of a user space API to set real time priority etc. is no guarantee that a kernel can provide hard RT response times.