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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2015-10-14 at 13:56 -0500, Christoph Lameter wrote:
> 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.

Yes, there is: PREEMPT_RT is (or can be if configured correctly) hard
real time.  The point, as Steve told you several times, is to sacrifice
performance for determinism.  As long as the general system deadlines
still fit, then the solution works ... well as it happens: this covers
many use cases because we sacrifice microseconds for millisecond
deadlines (or things even further apart in timescales); there's a huge
number of industrial use cases in this range.

What you're saying is that sacrificing performance is unacceptable for
your deadlines, so you're not able to use this solution: fair enough, it
doesn't cover all possible use cases, just a majority.  However trying
to imply that it's not a solution because it doesn't solve your problem
is really not going to motivate people involved to want to help you.

James