The realtime preemption end game — for real this time

[Posted September 6, 2024 by corbet]

Work on realtime preemption for the Linux kernel got its start almost exactly 20 years ago (though it had its roots in earlier work, of course). It is fair to say that finishing that job has taken a bit longer than anybody involved would have expected. Now, though, Sebastian Andrzej Siewior has posted a brief patch series making it possible to enable realtime preemption in the mainline kernel on three architectures.

With the printk bits merged, PREEMPT_RT could be enabled on X86, ARM64 and Risc-V. These three architectures merged required changes over the years leaving me in a position where I have no essential changes in the queue that would affect them.

Congratulations are due to the many developers who have worked on this project for the last two decades.

Really big celebrations are in order this time

Posted Sep 6, 2024 16:04 UTC (Fri) by Vorpal (guest, #136011) [Link]

Really? Is it time for mainline realtime?

This really needs a big celebration, will have time find some time for it.

(Sorry, but not sorry.)

For real though, that should make things simpler at my dayjob going for though.

What's next?

Posted Sep 6, 2024 16:48 UTC (Fri) by atnot (guest, #124910) [Link]

This is very exciting!

I'm really curious how things go from here what kernel configs are concerned. Since as things stand now, PREEMPT_RT is very much still a thing that requires a dedicated kernel build to have enabled, just because it conflicts with so much else. Which means that to end users, being mainline isn't really a huge difference. But we've also seen that set of things shrink a lot to the point that -rt kernels, while still needing to explicitly installed and requiring some compromises, are totally viable for daily use now (I have an rt config for audio work).

Will there be sufficient appetite to reduce this even further such that you can rely on preempt_rt being available in a distro kernel in 5 years without installing anything extra? Or is it niche enough to stay a very specialized config forever. Will there even be a point where the non-rt codepaths are just removed to simplify maintainance in another decade? I'm very curious and looking forward to it.

Congratulations!

Posted Sep 6, 2024 17:52 UTC (Fri) by Sesse (subscriber, #53779) [Link]

What a slog. The perseverance of everyone involved is impressive! Looking forward to realtime guarantees being widely available in another 20 years :-)

Been using PREEMPT_RT for years now

Posted Sep 6, 2024 18:06 UTC (Fri) by cruff (subscriber, #7201) [Link]

At work we have been using PREEMPT_RT on ARM boards for about 6 years now. Had a lot of issues with certain proprietary graphics drivers not fully working properly for some of the first few years and ran across an issue with high I/O loads from a container, but now it seems to have stabilized with the open source graphics driver.

the next goal is...?

Posted Sep 6, 2024 20:27 UTC (Fri) by jhoblitt (subscriber, #77733) [Link] (4 responses)

RT enabled by default?

the next goal is...?

Posted Sep 7, 2024 4:42 UTC (Sat) by alison (subscriber, #63752) [Link] (3 responses)

>RT enabled by default?

PREEMPT_RT has as its explicit goal to minimize the worst-case latency of high-priority tasks. The mainline kernel has as its explicit goal to optimize performance by maximizing hardware utilization. Software has no magic power to reconcile these goals, so turning on RT by default would not make sense, now or ever. Latency vs. performance is just one of the many configurable tradeoffs which depend on the use case.

the next goal is...?

Posted Sep 7, 2024 11:06 UTC (Sat) by Sesse (subscriber, #53779) [Link] (2 responses)

You could imagine a kernel that automatically switches modes depending on whether any high-priority tasks exist, for instance. But I guess that on a normal desktop, you'd always have PipeWire going…

the next goal is...?

Posted Sep 7, 2024 22:33 UTC (Sat) by alison (subscriber, #63752) [Link] (1 responses)

>on a normal desktop, you'd always have PipeWire going…

True, but /usr/bin/nice is enough for most normal desktop uses. Bottom line task management that doesn't need priority inheritance is unlikely to derive any benefit from PREEMPT_RT. There is a CONFIG_PREEMPT_DYNAMIC

https://elixir.bootlin.com/linux/v6.11-rc6/source/Documen...

but its behavior is different than what you describe.

the next goal is...?

Posted Sep 8, 2024 4:53 UTC (Sun) by joib (subscriber, #8541) [Link]

And maybe one day there will be PREEMPT_AUTO: https://lore.kernel.org/linux-kernel/af122806-8325-4302-9...

Puns must go on

Posted Sep 6, 2024 20:32 UTC (Fri) by intelfx (subscriber, #130118) [Link] (3 responses)

This article badly needs some sort of a time/realtime pun. :-)

Wordplay must go on!

Posted Sep 7, 2024 0:22 UTC (Sat) by python (guest, #171317) [Link] (2 responses)

Perhaps we can preempt this erroneous condition; puns must be delivered before it is too late!

Wordplay must go on!

Posted Sep 7, 2024 4:10 UTC (Sat) by fest3er (guest, #60379) [Link] (1 responses)

I heard from the rumor mill that Mott's are evaluating the possibility of deploying a just-in-time continuous process for a new product they are developing. It will be manufactured and shipped as case-lot orders arrive. I look forward to trying ultra-fresh realtime RealThyme™.

Sorry.

Wordplay must go on!

Posted Sep 7, 2024 13:18 UTC (Sat) by gus3 (guest, #61103) [Link]

This one should go into a fortune(6) database.