Hi Daniel, I hope we can discuss if-how Preempt-RT kernel can be tuned to benefit container/docker. It would involve any potential new interfaces, tools/utilities, etc, and how to make Preempt-RT work very well with some Linux secure features. Actually I tried to discuss this last year but for some reasons I did attend real-time micro-conference 2018, unfortunately. I hope we can have such a topic and I'd like to work on that as well. Thanks Tiejun > -----Original Message----- > From: linux-rt-users-owner@xxxxxxxxxxxxxxx <linux-rt-users- > owner@xxxxxxxxxxxxxxx> On Behalf Of Daniel Bristot de Oliveira > Sent: Friday, May 3, 2019 2:53 PM > To: linux-rt-users@xxxxxxxxxxxxxxx > Subject: Real-time micro-conference proposal for Linux Plumbers 2019 > > Hi all! > > Last year we had a very fun and productive real-time micro-conference at the > Linux Plumbers Conference, so the idea is to repeat it this year! > > Are you interested in participating? Do you have any suggestion of topic? Let us > know! > > This is the current proposal of micro-conference, we can still edit it and add your > thoughts. > > ======================== PROPOSAL > ============================== 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 needs > integration has been reduced on the last years, and the pieces left are now mature > enough to make its 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, the preempt-rt will > start to follow a new pace: the Linus one. So, it is possible to raise the following > discussions: > > 1) The status of the merge, and how can we resolve the last issues that block the > merge; > 2) How can we improve the testing of the -rt, to follow the problems raised as > Linus tree advances; > 3) What's next? > > Possible topics: > - Status of the PREEMPT_RT Merge > > - Merge - what is missing and who can help? > > - How do we teach the rest of the kernel developers how not to break > PREEMPT_RT? > > - Stable maintainers tools discussion & improvements. > > - Interrupt threads are RT and are not protected by the RT Throttling. > How can we prevent interrupt thread starvation from a rogue RT task? > > - Improvements on full CPU isolation > > - Newer methods like proxy execution, hierarchical scheduler? > > - What tools can we add into tools/ that other kernel developers can use to > test and learn about PREEMMPT_RT? > > - What tests can we add into 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. > > I will suggest the continuation of the discussions of the topics I presented last year, > based in the results of the work I did this year (spoiler: I am doing model > verification in the kernel, and it is very efficient!). > > Paul already told that he could talk about ongoing work to make RCU's forward > progress be more robust in overloaded cloud deployments. There will be some > connection to real-time response involving rcu_poll and the infamous RCU > kthread priority! > > The continuation of the discussion of topics from last year's micro-conference, > including the development done during this (almost) year, are also welcome! > > -- Daniel
