PREEMPT-RT Locking Infrastructure Possibly Ready For Linux 5.15

[phoronix]

Phoronix: PREEMPT-RT Locking Infrastructure Possibly Ready For Linux 5.15

Six dozen patches working on the PREEMPT-RT locking infrastructure for real-time kernels is now queued up in TIP's "locking/core" branch and will presumably be sent in for the Linux 5.15 merge window coming up quickly...

https://www.phoronix.com/scan.php?page=news_item&px=PREEMPT-RT-Sched-Core

[uid313]

Michael, please avoid the use of expressions such as "six dozens", just write the amount in plain numbers. I find it confusing with things such as "dozen", which I had to google and apparently means 12, so six dozen means 6 * 12 = 72, it's very confusing.

[timofonic]

Michael, please avoid the use of expressions such as "six dozens", just write the amount in plain numbers. I find it confusing with things such as "dozen", which I had to google and apparently means 12, so six dozen means 6 * 12 = 72, it's very confusing.

i agree. it's very confusing, specially for non native English people.

Please make PREEMPT-RT and any other RT efforts get merged in mainline.

[Linuxxx]

Please make PREEMPT-RT and any other RT efforts get merged in mainline.

Just curious:
Do you have some safety-critical hardware running in your basement or why do you exactly want a hard-realtime Linux kernel for your needs?

[Yttrium]

Michael, please avoid the use of expressions such as "six dozens", just write the amount in plain numbers. I find it confusing with things such as "dozen", which I had to google and apparently means 12, so six dozen means 6 * 12 = 72, it's very confusing.

dozen is an ubiqiuitous standard that is present in most countries and would it really matter wether there were a few dozen patches or 72?

why do you exactly want a hard-realtime Linux kernel for your needs?

Any 'realtime' problem like sound or games would benefit. any software without strict RT has to account for underruns which is an absolute pain and if you fail to do so you'll hear audible pops. preemt-rt would allow you to be more certain that loop x will have run by timestamp y

[wertigon]

Just curious:
Do you have some safety-critical hardware running in your basement or why do you exactly want a hard-realtime Linux kernel for your needs?

Hi, at a large company doing RT stuff for industry equipment and we want to cut our costs by using Linux, since this OS is massively popular, often known by new recruits, and has quite a lot of already implemented software for us to capitalize on.

We are not afraid to give back to the community in terms of bug reports, bug fixes and documentation but we are hesitant to put our own IP out there. Most of it is business logic in any case, wouldn't make much sense in a different project.

For us mainline RT would mean a lot of headaches gone actually, and we are looking forward to it. Currently the RT patch takes up to around 10 hours a week for our kernel guru, so some significant time saved here.

[Serafean]

Michael, please avoid the use of expressions such as "six dozens", just write the amount in plain numbers. I find it confusing with things such as "dozen", which I had to google and apparently means 12, so six dozen means 6 * 12 = 72, it's very confusing.

All languages I know have such a word. Granted, they're all european, but I have all the main families covered... "a few dozen" is a common way to fuzzily describe an amount. In all the languages I know. You know the xkcd "Every day 1/10000 people discover something new." Congratulations! You're one of them today! https://xkcd.com/1053/

[Linuxxx]

Any 'realtime' problem like sound or games would benefit. any software without strict RT has to account for underruns which is an absolute pain and if you fail to do so you'll hear audible pops. preemt-rt would allow you to be more certain that loop x will have run by timestamp y

In these cases a soft-realtime Linux kernel like Ubuntu's "lowlatency" flavor is more than adequate; plus it doesn't introduce security problems as described here:

About RealTime Kernels


Early on in Linux audio production, Real-Time kernels were the only way to get low- and no-latency audio for professional audio applications. However, since Linux 2.6, the real-time stack has been part of the Linux kernel, having a kernel patched with a real-time stack is no longer necessary.


RealTime Kernels Still Exist


However, there continued to be a demand for real-time kernels with a special patch. A patch does exist to enable process to have real-time process access to any process requesting it. This is good for applicance-like applications, such as audio mixers that use Linux (the Behringer X-series mixers and the Allen & Heath iLive series mixers are good examples). For desktop computer use, THIS IS A BAD IDEA.


Security Implications


All it would take is one malicious process to execute and take advantage of the real-time code to completely lock-out a user from their machine, turning that machine into part of a botnet or other malicious purpose. Real-Time processes have the potential to completely take-over a machine. This is the number one reason Ubuntu does not carry a Real-Time kernel.


Low-Latency Kernel


The Low-Latency Kernel included in Ubuntu Studio (and available in the Ubuntu repositories) does not allow such malicious code from locking-out a user from their machine. It does contain other optimizations to achieve the lowest possible latency for audio and other applications, while keeping the user interface usable. Latency as low as 0.1 millisecond can and has been achieved using this kernel.


Summary


For desktop computer usage, using a real-time kernel can cause security nightmares. The low-latency kernel included in Ubuntu Studio is completely capable of low- to no- latency while not enabling malicious processes to lock-out a user from their computer.

[Linuxxx]

Hi, at a large company doing RT stuff for industry equipment and we want to cut our costs by using Linux, since this OS is massively popular, often known by new recruits, and has quite a lot of already implemented software for us to capitalize on.

We are not afraid to give back to the community in terms of bug reports, bug fixes and documentation but we are hesitant to put our own IP out there. Most of it is business logic in any case, wouldn't make much sense in a different project.

For us mainline RT would mean a lot of headaches gone actually, and we are looking forward to it. Currently the RT patch takes up to around 10 hours a week for our kernel guru, so some significant time saved here.

This is exactly the type of field where a hard-realtime Linux kernel should be used more often!

Congratulations on making the jump!

And hopefully your employer really can help the Linux community one way or another in the future!

[MadeUpName]

Michael, please avoid the use of expressions such as "six dozens", just write the amount in plain numbers. I find it confusing with things such as "dozen", which I had to google and apparently means 12, so six dozen means 6 * 12 = 72, it's very confusing.

You'll like it even less when you find out there is a bakers dozen which is 13. Though I have never known a baker that sold any thing in a bakers dozen.