This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
realtime:rtl:blog [2019/02/15 18:58] lukas.bulwahn add a short notice on softirq rework |
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 ====== | ====== LWN.net: Softirq rework to improve softirq latency ====== | ||