Latest "sched/rt" Commits Point To PREEMPT_RT Potentially Being Ready For Linux 6.12

[phoronix]

Phoronix: Latest "sched/rt" Commits Point To PREEMPT_RT Potentially Being Ready For Linux 6.12

Excitement is building that the real-time kernel "PREEMPT_RT" support might finally be ready for the mainline kernel as soon as the upcoming Linux 6.12 merge window. It will be interesting to see if that long-awaited day finally comes this month but recently noted patches have now been queued into tip/tip.git's "sched/rt" branch ahead of the Linux 6.12 merge window...

https://www.phoronix.com/news/TIP.GIT-sched-rt-PREEMPT-RT

[Veto]

Hoping for some benchmarks quantifying the overhead for PREEMPT_RT for normal loads.

Also benchmarks quantifying the latency improvements would be nice, but that will probably require more specialized benchmarks.

[tomate]

Also benchmarks quantifying the latency improvements would be nice, but that will probably require more specialized benchmarks.

I don't know if this can apply here, but LinuxCNC has a latency test.

[ahrs]

Hoping for some benchmarks quantifying the overhead for PREEMPT_RT for normal loads.

Also benchmarks quantifying the latency improvements would be nice, but that will probably require more specialized benchmarks.

It'll be interesting to see if any everyday desktop software benefits from this. Will PipeWire run better with PREEMPT_RT support? What about my compositor, could Kwin_Wayland make use of this to avoid the stalls, etc, that sometimes happen under high load scenarios?

[spicfoo]

It'll be interesting to see if any everyday desktop software benefits from this. Will PipeWire run better with PREEMPT_RT support? What about my compositor, could Kwin_Wayland make use of this to avoid the stalls, etc, that sometimes happen under high load scenarios?

This is a common misunderstanding of what RT does. RT adds predictable latency to tasks and will slow things if that makes it more predictable. It is not a "go fast" knob.

[ssokolow]

This is a common misunderstanding of what RT does. RT adds predictable latency to tasks and will slow things if that makes it more predictable. It is not a "go fast" knob.

The question was about predictable latency under high load. The examples given were whether it could help to to keep audio playback and delivery of new frames by the desktop compositor from stuttering/stalling when other tasks are imposing high load.

[kiffmet]

It'll be interesting to see if any everyday desktop software benefits from this. Will PipeWire run better with PREEMPT_RT support? What about my compositor, could Kwin_Wayland make use of this to avoid the stalls, etc, that sometimes happen under high load scenarios?

I don't think it'll be particularily beneficial (full RT is more about determinism than always providing the lowest latency possible) and may additionally come with noticable performance overhead in some places. Tinker with process niceness or maybe try out the BORE scheduler:

IMO, the latest stable version (5.1.8 at the time of writing), together with voluntary preemption is very close to perfection. I can overcommit threads when compiling software and still have smooth video playback/not a single audio hickup while doing so.

It works by internally keeping a burstiness/greediness score which governs scheduling priority for each process. Due to that, CPU hogs are dynamically getting shorter timeslices, leaving some breathing room for non-bursty things like UI and media playback.

[ayumu]

Will PipeWire run better with PREEMPT_RT support?

Yes, it does. It already leverages SCHED_RR and priorities. These are available in all kernels, but work much better (and that's the point) with PREEMPT_RT.

[ayumu]

I don't think it'll be particularily beneficial (full RT is more about determinism than always providing the lowest latency possible)

Having guarantees about maximum latency is what hard realtime is about. Linux, by its sheer size, cannot provide these.

PREEMPT_RT is all about improving Soft Realtime. And it absolutely helps with audio latency (allowing smaller buffers, needed for serious audio work), as well as general responsiveness under load.

IMO, the latest stable version (5.1.8 at the time of writing), together with voluntary preemption is very close to perfection. I can overcommit threads when compiling software and still have smooth video playback/not a single audio hickup while doing so.

Audio is very easy when you are just listening to music, and your buffers are helluva large.

Try cyclictest from rt-tests. It sets an alarm, and waits for it (yielding execution), then measures the offset. Try its parameter to set policy to SCHED_FIFO, and enable SMP. The values displayed are usec. If you leave it running for long enough, you'll see spikes above 20000 or 20ms in the MAX column (the one that matters) with mainline kernel.

That really fucks serious live audio work, which runs pipelines at typically less than 10ms, often as low as 2ms.

With PREEMPT_RT, the situation visibly improves in cyclictest.

[aviallon]

Having guarantees about maximum latency is what hard realtime is about. Linux, by its sheer size, cannot provide these.

PREEMPT_RT is all about improving Soft Realtime. And it absolutely helps with audio latency (allowing smaller buffers, needed for serious audio work), as well as general responsiveness under load.



Audio is very easy when you are just listening to music, and your buffers are helluva large.

Try cyclictest from rt-tests. It sets an alarm, and waits for it (yielding execution), then measures the offset. Try its parameter to set policy to SCHED_FIFO, and enable SMP. The values displayed are usec. If you leave it running for long enough, you'll see spikes above 20000 or 20ms in the MAX column (the one that matters) with mainline kernel.

That really fucks serious live audio work, which runs pipelines at typically less than 10ms, often as low as 2ms.

With PREEMPT_RT, the situation visibly improves in cyclictest.

Have you tried using SCHED_DEADLINE, which is all about deterministic CPU bandwidth?