> On May 2, 2019, at 11:53 PM, Daniel Bristot de Oliveira <bristot@xxxxxxxxxx> wrote: > > 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’d definitely be interested in many of these topics at LPC. Hoping to make it. Thanks, Sean > > 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
