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
