PREEMPT-RT Locking Infrastructure Possibly Ready For Linux 5.15

[mppix]

Becuase I don't like random stutter on my low-latency audio.

Did you try pipewire with preempt-rt?

[tildearrow]

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?

Becuase I don't like random stutter on my low-latency audio.

[ferry]

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:

Yeah, this is non-sense. There is no reason a RT kernel must allocate all CPU to 1 process. All it must do is complete a task before a dead line. In fact, all CPU time after completing the task until the dead line is in principle available to other processes.

Also, the mentioned security problem happens on all linux kernels when you allocate so much memory the kernel starts swapping 100% of the time. A good way to try this is gitk on the linux git repo, while you have 4GB RAM (and 8GB swap). While gitk causes git to allocate more then physical RAM, swapping time is not considered by the kernel scheduler. This will lockup even your mouse and keyboard preventing you from terminating gitk (you might be able to ssh into your machine and SIGSTOP git, this will cause git to be swapped out and other processes to receive CPU time again).

Another fabulous example is building nodejs with > 4 threads on a machine with 16GB RAM (during linking there are 5 threads each requiring 4GB).

[mppix]

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:

These Ubuntu statements are very old and you can square them away as advertisement for 'how they do things'.

Soft real time/low latency can benefit gamers, consumer high-res audio, etc.
Hard real time is a different beast. It is for situations where your life depends on it (like reading and processing the video camera information of an autonomous car) or also where your work depends on it (like in a sound studio when you record a high $ musician).

Also, regarding the Ubuntu statements, it it is very difficult to completely lock a system with multicore cpu. Anyhow if you overrun the system capabilities, this tends to be the expected/preferred outcome in many hard-real-time systems as opposed to missing 'interrupts'.

[oiaohm]

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:

Soft-realtime still can benefit from hard realtime features restricted to kernel space. Lowlatency mode does not mean hard real-time features are not being used at all. That ubuntu write up focuses on that the real-time patch allows you to have true hard real-time user processes this skips over that a real-time patch applied kernel does have better lowlatency behavour and the fact ubuntu cherry picks a few parts out of the real-time patch set into their default kernel.

This locking infrastructure improvement from the PREEMPT-RT set is one of the parts that help lowlatency/soft realtime and hard realtime that had not got mainline yet.

[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.

[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!

[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.

[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/

[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.