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

[Tim Bird <tim.bird@sonymobile.com>]

On 10/14/2015 11:56 AM, 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.

This debate is as old as the hills. I remember having it in 2000 with
various parties, when talking about what used to be called the "dual-kernel"
approach.

> 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.

Check out Xenomai. (xenomai.org)  I think that's what many embedded folk use
if they find that RT-PREEMPT does not meet their needs.  Xenomai 3.0
allows you to use their system either on top of RT-PREEMPT or
on top of their Cobalt kernel sitting next to (or in front of,
depending on your perspective) the Linux kernel.

Sony used RT-PREEMPT in some products, and a dual-kernel in others,
and isolated CPUs running something else (usually uItron) in yet others.

Personally, I'd be happy to see RT-PREEMPT go in - there are certain use
cases for it.  I'd also like to see the NOHZ stuff go in as well.  It should
solve a set of problems for isolating RT tasks without sacrificing
performance on the non-RT CPUs.  And finally, I wouldn't mind putting
a non-Linux RT kernel like Cobalt (oh the horrors) into mainline as well.
Each of these approaches has their strengths and weaknesses.  Linux is,
after all, whatever we say it is - and it could easily have a small RT
micro-kernel as part of the source base as well.

AFAIK the patent issues that plagued the dual-kernel approach are now
behind us, so this might be a good area of investigation.

I've long felt that RT-PREEMPT was sucking the oxygen out of getting other,
technically valid, approaches to RT with Linux into mainline.
 -- Tim