User Tools

Site Tools


realtime:rtl:blog

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
realtime:rtl:blog [2018/08/21 09:32]
lukas.bulwahn include BMW Car IT's blog post with a disclaimer
realtime:rtl:blog [2022/11/15 13:06] (current)
lukas.bulwahn Add further LWN.net articles
Line 1: Line 1:
 +====== LWN.net: Better CPU selection for timer expiration ======
 +
 +Jonathan Corbet describes Anna-Maria Behnsen'​s work on better CPU selection for timer expiration [[https://​lwn.net/​Articles/​913568/​]].
 +
 +====== LWN.net: A discussion on printk() ======
 +
 +Jake Edge summarizes the discussion around printk() in a LWN.net article [[https://​lwn.net/​Articles/​909980/​]]. It is the last core piece needing changes before the RT_PREEMPT patches can be fully merged.
 +
 +
 +====== An update on real-time is overdue ======
 +
 +As there has not been a recent blog post in the last ten months, one might believe the real-time Linux project is not progressing any further, but quite the opposite is true.
 +
 +So, let's briefly point out the recent news and developments:​
 +
 +  * In April 2021, Thomas Gleixner has given an interesting interview on the history, current state and challenges of real-time Linux. The interview clearly shows that the technical challenges are well understood and can be resolved with the community. The actual challenge for the success of progressing real-time Linux is the mismatch of seeming relevance and reliance of various industry partners on the real-time functionality to the active contributions and support for the needed development and maintenance activities. Thomas Gleixner points out that the "​Tragedy of the Commons"​ situation, with each individual company thinking their own minor contribution might not make a difference, can lead to a situation that makes the whole industry suffer the self-created lack of quality assurance and maintenance for real-time Linux in the future. He made very clear that the decisions made now will set the path to the future. Even though a lot of effort and success story surround the technical work on real-time Linux, the world can continue with a future without real-time Linux; it will be just devastating to those stakeholders that never concluded to ever support something they so centrally rely on in their business. Read more at https://​www.linux.com/​news/​in-the-trenches-with-thomas-gleixner-real-time-linux-kernel-patch-set/​.
 +  * In May 2021, Thomas Gleixner presented "A Guided Tour Through the PREEMPT_RT castle."​ at the ELISA (Enabling Linux In Safety Applications) Workshop. Read more and tune into the presentation at https://​elisa.tech/​blog/​2021/​08/​25/​a-guided-tour-through-the-preempt-rt-castle/​.
 +  * In August 2021, a large core part of the out-of-tree PREEMPT_RT patch set, the PREEMPT_RT locking core, has been finally merged. As always, Jonathan Corbet briefly mentions it in two LWN.net articles, https://​lwn.net/​Articles/​866112/​ and https://​lwn.net/​Articles/​867821/​. For the ones interested in digging into more details, the git merge commit may serve as a good entry point: https://​git.kernel.org/​pub/​scm/​linux/​kernel/​git/​torvalds/​linux.git/​commit/?​id=e5e726f7bb9f. With that part merged, mainlining the PREEMPT_RT is not yet finished, but did a big step forward.
 +  * In September 2021, the annual Real-time Microconference has taken place as part of the Linux Plumbers Conference. The real-time Linux developers have been talking about current and future development. See more at https://​linuxplumbersconf.org/​event/​11/​sessions/​108/#​20210921.
 +
 +
 +====== The real-time endgame is moving quickly now ======
 +
 +As the real-time endgame, i.e.,  the stage of the game when few pieces are left on the board, continues advancing, Jonathan Corbet summarizes the development work on mainlining ​ [[https://​lwn.net/​Articles/​836503/​| migration disabling in the scheduler]]. It nicely sketches the well-known tug of war between optimizing for minimal latencies and maximal throughput and how the kernel community iteratively works towards a solution that allows peaceful coexistence of both worlds.
 +
 +And this is just one of many moves happening quickly now in this endgame, Jonathan Corbet has also reported on other activities related to the real-time work in the core kernel in further articles [[https://​lwn.net/​Articles/​836144/​|Atomic kmaps become local]] and [[https://​lwn.net/​Articles/​831678/​|Four short stories about preempt_count]].
 +
 +Our real-time application developers also get a nice introduction from John Ogness to make full proper use in their applications of the real-time kernel with the Embedded Linux Conference Europe (ELCE) 2020 presentation [[https://​ogness.net/​ese2020/​ese2020_johnogness_rtchecklist.pdf|A Checklist for Writing Linux Real-Time Applications]]. Marta Rybczyńska has also summarized this great presentation in yet another LWN.net article [[https://​lwn.net/​Articles/​837019/​|A realtime developer'​s checklist]].
 +
 +====== LWN.net: Preparing for the realtime future ======
 +
 +Jake Edge summarizes the discussion around planning maintenance of the real-time work once the PREEMPT_RT branch is fully merged in mainline in the LWN.net article [[https://​lwn.net/​Articles/​830660/​]]. This already gives an interesting view of the work ahead when the first goal, the out-of-tree branch is fully merged, has been reached.
 +
 +
 +====== LWN.net: Local locks in the kernel ======
 +
 +Marta Rybczyńska summarizes the Real-time Linux Project'​s work on making the locking APIs carry more semantic information,​ and hence allow the underlying kernel execution to be safe when being more flexible, e.g., allow more kinds of preemption, in the LWN.net article [[https://​lwn.net/​Articles/​828477/​|Local locks in the kernel]]. This article shows nicely the needs and challenges on reworking the kernel'​s core API "just to make Linux real-time, but done right"​. Initially motivated by the needs for real-time systems, the locking API in the kernel has improved in clarity for the overall kernel community, i.e., all kernel developers and users.
 +
 +
 +====== The jury has spoken ======
 +
 +Linus Torvalds, the Linux Kernel top level maintainer, [[https://​git.kernel.org/​pub/​scm/​linux/​kernel/​git/​torvalds/​linux.git/​commit/?​id=70e6e1b971e46f5c1c2d72217ba62401a2edc22b|merged a pull request]] adding the kernel configuration symbol CONFIG_PREEMPT_RT. The configuration symbol is currently hidden as it depends on a not yet enabled option which means it has absolutely no functional technical value at the moment.
 +
 +The value is elsewhere. As stated in the pull request mail, the ongoing effort of merging the real-time preemption patch set into the mainline kernel ran into a hen and egg problem. While the preparatory work which was conducted in the past four years was mostly undisputed because it provided benefit to the mainline kernel independent of real-time support, the remaining bits and pieces are of different nature. They require rework of code which is from a mainline perspective perfectly fine. While upstream maintainers are generally very supportive towards the real-time efforts, they rightfully started to ask the question why these changes should be merged if there is no clear indication that the real-time preemption patch set will be fully integrated into the mainline kernel.
 +
 +Adding CONFIG_PREEMPT_RT as a for now hidden configuration symbol addresses exactly this problem. It's a clear sign that real-time will be a first class citizen of the mainline kernel. That answers the question of maintainers and opens the flood gates for the outstanding (hard)core real-time bits. Of course this is not a free pass for forcing the missing bits and pieces into the mainline kernel. No, the real-time developer team will continue the careful and responsible integration as it has done for the past 15 years.
 +
 +Quite some work ahead, but with a bit of luck most of the important changes could be queued in maintainer trees by mid of September and be ready to be merged into the mainline kernel during the Linux v5.4 merge window. Accidentally that will be almost exactly 15 years after the big real-time flame wars took place on the Linux Kernel Mailing List and 20 years after real-time project lead Thomas Gleixner started to investigate the options for Linux and real-time.
 +
 +The real-time developer team wants to take this opportunity to express gratitude for the support and the trust we received from the [[realtime:​rtl:​members|members]] of the Real-time Linux collaborative project and the Linux Foundation. We are excited that the hard work of the past years brought us to the point where the most interesting chapter of the long and thrilling story of Real-time Linux will be written.
 +
 +====== LWN.net, the second: Real-time Linux Project'​s printk() reimplementation ======
 +
 +Jake Edge summarizes John Ogness work on redesigning printk() in the LWN.net article [[https://​lwn.net/​Articles/​780556/​|Reimplementing printk()]].
 +
 +While at first, it might seem that printk() and real-time systems are unrelated, it turns out that to guarantee low latencies, all parts of the kernel need to become interruptible,​ and for printk(), the best way to do so is to make the design as lockless, interruptible and concurrent as possible. Once John Ogness has got his reimplementation upstream, the PREEMPT_RT patch set will decrease by a few earlier work-around patches on printk. Hence, we are getting another step closer down to the core real-time parts and the final patch providing the ultimate `real-time` config switch.
 +
 +====== LWN.net: Softirq rework to improve softirq latency ======
 +
 +Jonathan Corbet reports on Frederic Weisbecker'​s softirq rework to reduce softirq latency in the LWN.net article [[https://​lwn.net/​Articles/​779738/​|Per-vector software-interrupt masking]].
 +
 +This work is yet another step to make the kernel more real-time capable, and doing it in a manner that it generally improves the softirq design in the kernel. Merging PREEMPT_RT mainline is all about refactoring various kernel functionalities to be properly and cleanly designed with respect to minimizing latencies. This means to minimize sections of non-interruptible executions, defer work to interruptible tasks and reduce dependencies between the executions of multiple kernel threads. The softirq rework is one step on the Linux Real-time Project'​s trail to mainline.
 +
 +====== We missed the train - we are taking the bus ======
 +
 +=== We missed the train ===
 +
 +The goal of getting the remaining bits and pieces of Preempt-RT merged into the 2018 LTS kernel has always been ambitious, but we were working hard on making it. The assumption that 4.20 will be the next LTS kernel turned out to be wrong, which clearly made us miss the train.
 +
 +Though blaming everything on the decision to select 4.19 as the next LTS kernel would be dishonest at best. There are a lot of other factors which led to this. 
 +
 +  * The last year, since the speculation vulnerabilities started to surface, has been tough for a lot of key developers and maintainers in the kernel community and occupied many of them for a long period of time. The complexity of these vulnerabilities and the fact, that these issues forced us to destroy performance optimizations which we carefully built over time based on the assumption that the hardware holds up to the promises of protection domains, caused a lot of disruption not only for the RT development. Review and feedback cycles got significantly longer which caused delays in the range of months.
 +  * Several tasks which were thought of as easy to solve turned into rather large work packages due to upstream changes and upstream maintainer feedback, refactoring the USB completion callback being only one of the examples.
 +  * The time spent on tracking down subtle and hard to debug issues increased significantly in the last year. Most of these issue turned out to be upstream problems, which were exposed by RT. The recent analysis of a nasty [[https://​lkml.kernel.org/​r/​20180921120226.6xjgr4oiho22ex75@linutronix.de|cache line starvation problem]] accumulated to more than a month of work and it's still not fully resolved.
 +
 +=== We are taking the bus ===
 +
 +Having missed the LTS goal, the project members agreed thankfully that rushing everything into 4.20 just to be able to tick off a box in a spread sheet, does not make sense. ​
 +
 +There has been a substantial amount of overtime accumulated in the RT team, so relaxing the time line a bit and giving the people their well deserved recreation time is surely better than rushing things for no real value.
 +
 +There needs to be quite some effort made to switch over from the half stabilized 4.18-RT to 4.19-RT and it surely needs a lot of thought to make the LTS support for 4.19-RT as smooth as possible by aligning it as much as we can foresee to the final state of RT.
 +
 +This also allows to take a step back and revisit some of the design decisions and we are looking forward to RT-Summit and the LPC RT microconference for fruitful technical discussions.
 +
 +As always I want to take the opportunity to express my gratitude for the support of this effort by the RT project members and their understanding for unexpected roadblocks.
 +
 +
 ====== Guest Blog Post from BMW Car IT: Real-time Linux continues its way to main-line development and beyond. ====== ====== Guest Blog Post from BMW Car IT: Real-time Linux continues its way to main-line development and beyond. ======
  
Line 24: Line 112:
 The real-time functionality touches the core kernel parts, i.e., it requires significant changes in timers, schedulers, locking mechanisms, interrupt handling and more, and it also is a cross-cutting concern for all drivers, i.e., every driver has to follow a certain discipline to make the overall kernel real-time capable. Hence, it is difficult to predict the exact date when the Real-time Linux Project will finally have all its patches merged into the main-line development. However, there is no doubt that the Linux kernel will eventually become real-time capable. The real-time functionality touches the core kernel parts, i.e., it requires significant changes in timers, schedulers, locking mechanisms, interrupt handling and more, and it also is a cross-cutting concern for all drivers, i.e., every driver has to follow a certain discipline to make the overall kernel real-time capable. Hence, it is difficult to predict the exact date when the Real-time Linux Project will finally have all its patches merged into the main-line development. However, there is no doubt that the Linux kernel will eventually become real-time capable.
  
-"The Linux kernel is a software development project of huge interest ​to us. Obviously, BMW Car IT has a high interest of making best possible use of this software asset. The automotive industry has particular requirements,​ such as higher real-time requirements and the need for longer maintenance periods, than the general IT and consumer electronics industry. With our investments in initiatives addressing these requirements,​ we can ensure that Linux fits to our needs",​ says Kai-Uwe Balszuweit, the CEO of BMW Car IT.+"The Linux kernel is a software development project of huge invest ​to us. Obviously, BMW Car IT has a high interest of making best possible use of this software asset. The automotive industry has particular requirements,​ such as higher real-time requirements and the need for longer maintenance periods, than the general IT and consumer electronics industry. With our investments in initiatives addressing these requirements,​ we can ensure that Linux fits to our needs",​ says Kai-Uwe Balszuweit, the CEO of BMW Car IT.
  
 Once the real-time capabilities have been integrated in the main-line development,​ the project work is of course not just finished and the Real-time Linux project cannot just be abandoned. After the final integration into the main-line development,​ the development Once the real-time capabilities have been integrated in the main-line development,​ the project work is of course not just finished and the Real-time Linux project cannot just be abandoned. After the final integration into the main-line development,​ the development
Line 141: Line 229:
  
 ---- ----
- 
realtime/rtl/blog.1534843963.txt.gz · Last modified: 2018/08/21 09:32 by lukas.bulwahn