The PREEMPT_RT Locking Code Is Merged For Linux 5.15

[phoronix]

Phoronix: The PREEMPT_RT Locking Code Is Merged For Linux 5.15

It looks like the real-time (RT) patches for the Linux kernel are almost to the point of being fully upstream in the mainline Linux kernel. Merged for Linux 5.15 is the PREEMPT_RT locking code that represents a bulk of the outstanding RT patches...

https://www.phoronix.com/scan.php?page=news_item&px=PREEMPT-RT-Locking-In-Linux-515

[mppix]

Yeeeh!
Congratulations and thank you to everyone involved in preempt_rt!

[wertigon]

Sweet! It only took 2 years, but finally it is in!

If Phoronix want to do a little more investigative journalism here, the "series" file in the patch set details status of all patches to date, will be interesting to see how this file looks for 5.15

https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/series?h=linux-5.14.y-rt-patches

[uid313]

Would any benefit of a RT kernel for normal users?
Would enabling RT on the kernel have any negative effect for users who don't care about RT or do use any applications that make use of RT?

Maybe some users want to do things like audio but without having to use special kernels.
How is the RT on other systems such as macOS and Windows?
I heard that RT can be good for audio, and there are people who make music on macOS and Windows.

[zaro]

Would any benefit of a RT kernel for normal users?
Would enabling RT on the kernel have any negative effect for users who don't care about RT or do use any applications that make use of RT?

Maybe some users want to do things like audio but without having to use special kernels.
How is the RT on other systems such as macOS and Windows?
I heard that RT can be good for audio, and there are people who make music on macOS and Windows.

No, this is for systems with hard RT guarantees, and while it should be harmless to enable, there might be drawbacks.

You don't need this patch for audio processing, I believe the soft rt support required for that has been in the kernel for long time.
Non existent, if you want to compare to other OS try maybe QNX

[perpetually high]

The -rt kernel benchmarks *terribly* also, so you better have a use-case for it. You also can't use VirtualBox if that's important to you. I'm no longer that interested in the -rt patches unless I'm doing some gaming that I feel could benefit from it. (I notice a difference in quake 2 multiplayer deathmatch if it matters. Subtle, but I notice it).

Edit: case in point, just booted into the newest 5.4.143-rt:

$ uname -a
Linux ubuntu 5.4.143-0504143+customrt-generic #0504143+202107311230 SMP PREEMPT_RT Tue Aug 31 03:51:20 PDT 202 x86_64 x86_64 x86_64 GNU/Linux
$ dmesg | grep -i 'BUG'
...
[ 6.872577] BUG: scheduling while atomic: preload/1294/0x00010001
[ 6.872577] BUG: scheduling while atomic: snapd/1171/0x00010001
[ 6.872604] __schedule_bug.cold+0x4c/0x58
[ 6.872651] __schedule_bug.cold+0x4c/0x58
[ 6.872996] BUG: scheduling while atomic: preload/1294/0x7fff0001
[ 6.873004] __schedule_bug.cold+0x4c/0x58
[ 6.873783] BUG: scheduling while atomic: snapd/1171/0x7fff0001
[ 6.873790] __schedule_bug.cold+0x4c/0x58

It's just highly unpredictable depending on what you're running (snapd and preload as shown above).

I've also had times where it doesn't boot, then I'll hit the reset button, boots no problem. Just random stuff. I prefer not to use the -rt kernel anymore as I like deterministic behavior and I'm probably not even a prime candidate to be using it.

[kbios]

No, this is for systems with hard RT guarantees, and while it should be harmless to enable, there might be drawbacks.

You don't need this patch for audio processing, I believe the soft rt support required for that has been in the kernel for long time.
Non existent, if you want to compare to other OS try maybe QNX

Well, for me using the RT kernel is the difference between having or not having xruns in jackd, so it does have an impact

[caligula]

Maybe some users want to do things like audio but without having to use special kernels.
I heard that RT can be good for audio, and there are people who make music on macOS and Windows.

The RT stuff is really only useful to those who have a DAW. Idiots having 1536 kHz 32 bit DACs for playing back HD web streams somehow believe they'd need 0,1 ms latency and 128 bits of dynamic range for no reason.

[uid313]

The RT stuff is really only useful to those who have a DAW. Idiots having 1536 kHz 32 bit DACs for playing back HD web streams somehow believe they'd need 0,1 ms latency and 128 bits of dynamic range for no reason.

Yeah, I kinda figured that RT was useless for playback, but I meant for audio creation such as music making and stuff you would do with a DAW.
So I was thinking like a scenario where a person normally doesn't do any RT stuff, like normally Bob just plays games, listen to music, browse the web, and watches movies, but sometimes, quite rarely he would like to start up his DAW.

So Bob might not want a RT kernel if its going to have negative impact on his gaming performance, but he still might occasionally need some to do some digital audio work.

[sinepgib]

Would any benefit of a RT kernel for normal users?
Would enabling RT on the kernel have any negative effect for users who don't care about RT or do use any applications that make use of RT?

Maybe some users want to do things like audio but without having to use special kernels.
How is the RT on other systems such as macOS and Windows?
I heard that RT can be good for audio, and there are people who make music on macOS and Windows.

Take with a grain of salt, but essentially when you use real time you trade off throughput for responsiveness. You have deadlines to fulfill so you limit how much time a given task can take at the cost of interrupting tasks more often, which adds overhead and limits how much individual processes can do in a given time slice. That's why it may be good for audio and gaming, as it will reduce skipped frames because some process took too much time before giving a slot back to your game, but compute intensive tasks will take longer to complete.