Re: [Ksummit-discuss] [TECH TOPIC] Mainlining PREEMPT_RT

[Christoph Lameter <cl@linux.com>]

On Wed, 14 Oct 2015, Steven Rostedt wrote:

> If PREEMPT_RT is not the way to go, then why did several companies just
> invest into getting it mainlined?

I guess they want "realtime" support. Better talk to them what they mean
by realtime. I have never seen a real use case for PREEMPT_RT. Instead a
lot of high level "realtime" talk and disappointment when they found out
what the real constraints and limitations are.

> Again, real-time does not mean real-fast. How do you handle priority
> inversion? How do you handle outliers? Which the Linux kernel has many
> huge outliers if things are not handled correctly, which PREEMPT_RT
> solve (making it, by the way, a hard real time design).  If you can
> accept a single outlier, then that's soft real-time, and you are
> talking about something completely different.

You could put the processing for the stuff that creates outliers on a
different cpu? Layout the processing in such a way to guarantee no
outliers on the "realtime" processors?

> Hard real-time is about worse case latency, not the average latency.
> That's called "soft real-time"

Of course. Thats why I suggested combining it with the NOHZ appraoch. Put
the pieces that can create outliers on cpus not used for "realtime"
threads. Ensure that what is running on a hard realtime cpu can complete
in a defined timed interval.

Realtime is about guarantees of a response in a certain time period. That
is why "soft realtime" is not making much sense. There is no guarantee
anymore. Just more overhead. OS processing slows down due to the
sprinkling of preempt code but the timing guarantees that one seeks can be
violated. Increasing the processing overhead may increase the number of
failures to process a given task in a time period that one wants
guaranteed. So better run without preempt in order to have a higher chance
to finish in time? That is at least what my industry has decided to do.

But we really wish we had a hard realtime capability if we must respond in
a certain time period. Sadly there is no solution in sight right now.