Real-Time / PREEMPT_RT Support Should Finally Be Mainlined Soon In The Linux Kernel

[cynic]

would it be useful for generic desktop user (ie: more fluent desktop experience) or is it suitable only for specific workloads (music? high frequency trading?)

[indepe]

Either way if you game with RT enabled your framerates will be lower

I'm sure Michael will test this. It could be that the patches were tuned exclusively for audio processing, and (at that point in time) ignoring other granularities (like frame rates). However it could also be that the additional locking used to enable preemption really is noticeably less efficient.

As a side note, I wonder if in today's multi-CPU world it would be easier to have one or more CPUs free from kernel task duties, such that they could run things like audio processing (or like frame rate related processing), without requiring kernel preemption. Dynamic variations of 'isolcpus'.

[unic0rn]

I'm sure Michael will test this. It could be that the patches were tuned exclusively for audio processing, and (at that point in time) ignoring other granularities (like frame rates). However it could also be that the additional locking used to enable preemption really is noticeably less efficient.

As a side note, I wonder if in today's multi-CPU world it would be easier to have one or more CPUs free from kernel task duties, such that they could run things like audio processing (or like frame rate related processing), without requiring kernel preemption. Dynamic variations of 'isolcpus'.

few months ago i did some tests on manjaro kde, running on A8-7600 (integrated graphics). kernel 5.6 vs 5.6 RT, the framerate difference in games was reaching 2-digit numbers, RT was even 20fps slower. it was MASSIVE.

hopefully noone will think about enabling it by default.

[jabl]

would it be useful for generic desktop user (ie: more fluent desktop experience) or is it suitable only for specific workloads (music? high frequency trading?)

It's mostly for specific workloads that request RT scheduling (e.g. SCHED_RR or SCHED_DEADLINE), and are very carefully written. Some music stuff, yes. The big usecase is various control systems. Think industrial robots and such.

AFAIK Linux isn't used for safety-critical RT systems like avionics, since the codebase is so huge it's impossible to formally prove it works as designed.

[jabl]

However it could also be that the additional locking used to enable preemption really is noticeably less efficient.

Yes, it really is. A lot of Linux performance, and in particular scalability, is by using per-cpu data structures and algorithms. On a non-RT kernel this works beautifully with low overhead by simply disabling interrupts in the critical section. But on a RT kernel this isn't acceptable, in case a high priority RT thread wants access to the CPU. So with the PREEMPT_RT patch these per-cpu locks are replaced by mutexes.

Also spinlocks which are extensively used in the non-RT kernel in most cases have to be replaced with (adaptive) mutexes, again increasing locking overhead.

As a side note, I wonder if in today's multi-CPU world it would be easier to have one or more CPUs free from kernel task duties, such that they could run things like audio processing (or like frame rate related processing), without requiring kernel preemption.

AFAIK there exist various "RT hypervisors", where you can allocate some cores for RT tasks, and run some barebones RT OS or even a bare-metal RT application, and on the other cores you can run a normal non-RT Linux kernel to provide all the usual OS services.

[muncrief]

I used to run RT kernels because they were once required for pro audio on Linux. But though I could still benefit from the lower latency for audio, RT is no longer strictly required and I've never been able to run KVM with them. But hopefully once the devs are done with RT that will change.

[furkantokac]

Big step for the humanity!

[pal666]

RT is predictability in scheduling and latency. I.e a consistent output.

actually it's upper bound on response time(which can be arbitrarily large btw, but known in advance)