Re: Real-time micro-conference proposal for Linux Plumbers 2019

["Stéphane Ancelot" <sancelot@numalliance.com>]

Hi guys,

That's a good job. Regarding this topic, I would be interested in 
knowing the future of network drivers in preempt RT.

At the moment, it is mandatory to hack any network driver, if you want 
to achieve realtime.

This would imply inhibit some layer functions of the driver (eg vlan, 
etc ...).

The NAPI model in network drivers is not really compatible with RT tasks.

To achieve this task , I would suggest network driver architecture must 
adopt an enhanced driver model .

This may be some work planning.

Regards,

S.Ancelot


Le 03/05/2019 à 08:53, Daniel Bristot de Oliveira a écrit :
> 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