Since 2004 a project has improved the Real-time and low-latency features for Linux. This project has become know as PREEMPT_RT, formally the real-time patch. Over the past decade, many parts of the PREEMPT RT became part of the official Linux code base. Examples of what came from PREEMPT_RT include: Real-time mutexes, high-resolution timers, lockdep, ftrace, RT scheduling, SCHED_DEADLINE, RCU_PREEMPT, generic interrupts, priority inheritance futexes, threaded interrupt handlers and more. The number of patches that need integration has been reduced from previous years, and the pieces left are now mature enough to make their way into mainline Linux. This year could possibly be the year PREEMPT_RT is merged (tm)!
In the final lap of this race, the last patches are on the way to be merged, but there are still some pieces missing. When the merge occurs, PREEMPT_RT will start to follow a new pace: the Linus one. So, it is possible to raise the following discussions:
The status of the merge, and how can we resolve the last issues that block the merge;
How can we improve the testing of the -rt, to follow the problems raised as Linus's tree advances;
Proxy execution discussion
Merge - what is missing and who can help?
Rework of softirq - what is need for the -rt merge
An in-kernel view of Latency
Ongoing work on RCU that impacts per-cpu threads
How BPF can influence the PREEMPT_RT kernel latency
Core-schedule and the RT schedulers
Stable maintainers tools discussion & improvements.
Improvements on full CPU isolation
What tools can we add into tools/ that other kernel developers can use to test and learn about PREEMPT_RT?
What tests can we add to tools/testing/selftests?
New tools for timing regression test, e.g. locking, overheads...
What kernel boot self-tests can be added?
Discuss various types of failures that can happen with PREEMPT_RT that normally would not happen in the vanilla kernel, e.g, with lockdep, preemption model.
The continuation of the discussion of topics from last year's microconference, including the development done during this (almost) year, are also welcome!
If you are interested in participating in this microconference and have topics to propose, please use the CfP process. More topics will be added based on CfP for this microconference.
Daniel Bristot de Oliveira firstname.lastname@example.org
Recently speculative execution techniques have shown that an untrusted application can steal data from another one when both share the same core. To avoid such problems users have to disable SMT, causing non-negligible performance impact. Core-scheduling tries to mitigate the performance problem by allowing trusted applications to run concurrently on siblings of a core while avoiding two...
RCU has changed a surprising amount over the past few years, what with elimination of many RCU Kconfig options in favor of kernel boot parameters, RCU flavor consolidation, ongoing work on speeding up RCU's handling of offloaded callbacks, and newly started work on providing warnings when RCU's callback handling is overloaded. These changes affect how RCU behaves, and in some cases in ways...
I'd like to review if-how we can build real-time container. It should include but not limited these topics here,
- Understanding container Scheduling
- Test and evaluations
- Possible factors related to latency issues
- discussions like tracing containers-leveled metrics
We know that reducing the sections with preemption and IRQ disabled reduces the latency, also that IRQs influences on it, but some cases are hard to catch. For example, in the old jump label update, there was a burst of IPIs causing latency spikes. Such non-periodic behavior is hard to mathematize. As a side effect, this adds pessimism to "possible formulas" that tries to define the worst-case...
Which Real Time softirq implementation do we want for mainline?
_ Vector-Lock based? (depend on sleeping spinlocks machinery) _ Vector masking based? _ Other?
_ What is needed upstream for real time support of Full Dynticks and isolation? _ Specific requests?