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

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 15 Oct 2015, Thomas Gleixner wrote:

> On Thu, 15 Oct 2015, Christoph Lameter wrote:
> > On Wed, 14 Oct 2015, Thomas Gleixner wrote:
> > 
> > > Sure, you just add another server to it and be done. That's not what
> > > people in the embedded space can do.
> > 
> > Why not? Seems that even small devices have multiple cores? I just got a
> > quad core cheapo phone for $50. Even the Intel Edison platform is dual
> > core. So it may be possible to have deterministic hard real time on one
> > core.
> 
> That fits into all current use cases of Preempt-RT how?
> 
> Please come up with a functional concept for applications like PLCs
> (Programmable Logic Controllers) where the end customer defines the
> application and therefor the number of involved thread and their
> particular deadline requirements. That would for a change start a
> useful discussion instead of your 'spend a CPU' mantra.
> 
> > > They need to run highly multi threaded applications on a small system
> > > and still need the guarantee that they meet their dead lines. They
> > > cannot afford the waste of a CPU busy spinning in order to process the
> > > next event. Neither they have the number of cores which would be
> > > needed nor they can afford the energy wasted by it.
> > 
> > There could be deterministic wake up logic for real time cpus? If you can
> > push off most of the effort on another cpu its likely possible to make the
> > behavior much more deterministic for a cpu that does real time processing.
> > Why does spinning come up here?
> 
> Because that is what you and others do to solve your particular
> problem, but it does not work for a application like Motion Control,
> where you have a hierarchical control mechanism running in different
> threads with different priorities, different code execution times and
> different deadline requirements.
> 
> > > Once again: The definition of Real-Time is determinism, not speed.
> > 
> > Yes then please do deterministic latencies. No exceptions. No soft
> > realtime.
> 
> Preempt-RT is not about soft realtime. It gives you hard guarantees
> versus your defined deadlines, but only when the deadline fits into
> the limitations of the hardware and the OS.
> 
> Realtime is not about as fast as possible, it's about as fast as
> specified. And that specified can be anything from nanoseconds to
> seconds or even hours.
> 
> The point is, if you miss your deadline, no matter how big or small
> that deadline is, it's going to be a violation of the guarantee.
> 
> So if your deadline requirements are in a range which cannot be
> satisfied by PREEMPT-RT, then you need a different solution. Bare
> metal busy looping or whatever.
> 
> > > You're design goal is completely different. Your design goal is
> > > sacrifying a single CPU in order to have FAST response on an event and
> > > high throughput at the same time. That has nothing to do with real
> > > time. Go and read on OS theory to figure out why.
> > 
> > ???. Please stay on topic. Maybe you would have benefited from the
> > clases on OS design that I taught. But maybe reading comprehension would
> > be much more urgent.
> 
> Lets start to talk about the terms used.
> 
> Deadline: The maximum time between an event which triggers a
> 	  computation and the time when the computation has completed.
> 
> Latency:  There are two types of latency:
> 
> 	  1) The delta between the desired time of starting a computation
> 	     and the actual start of the computation.
> 
> 	  2) The delta between the theoretical execution time of a
> 	     computation and the actual execution time
> 
> So the mathematical definition of a real-time system is:
> 
>    Te:  Trigger time of the computation
>    Td:  The relative from from Te to completion of the computation,
>         aka deadline
>    Tsl:	The delta between Te and actual start of the computation
>    Trt:	The theoretical (optimal) runtime of the computation
>    Trl:	The delta between Trt and the actual runtime of the computation
> 
>    Ergo:
> 
>    Te + Td < Te + Tsl + Trt + Trl

That of course wants to be

     Te + Td > Te + Tsl + Trt + Trl

> 
>    Any OS which can guarantee that under all circumstances qualifies
>    as a hard real time OS.
>  
> The hardware and the OS define the maximum values of
> 
>    Trt is defined by the optimal performance of the hardware when the
>    computation runs completely undisturbed.
> 
>    Tsl and Trl are influenced by both hardware and OS. So we get
>    maximum values for Tsl and Trl: Tsl_max and Trl_max.
> 
> So for a given computation you can compute the deadline guarantee of a
> given system:
> 
>    Td < Tsl_max + Trt + Trl_max

Ditto

     Td > Tsl_max + Trt + Trl_max

Time for bed. :)
 
> The application specifies Td, i.e. the deadline. If your applications
> deadline requirements do not fit into the deadline guarantee of the
> given hardware/OS combination, then you need to look after a different
> solution.
> 
> Preempt-RT has its limitations how small Tsl_max and Trl_max can
> become. But within these limitations it gives you the guarantee that
> you meet your deadline.
> 
> So for applications, and those are real world applications which use
> Preempt-RT today, which can tolerate the slightly larger latencies,
> but at the same time require the functionality of a full blown OS
> including load balancing and scheduling of non-RT background work on
> multicore systems, Preempt-RT is the appropriate choice.
> 
> For other applications, which aim for way lower Tsl_max and Trl_max,
> NOHZ_FULL might be the solution if they can spend a core for a
> particular computation.
> 
> There are certainly applications out there which need both. Preempt-RT
> on one set of cores to handle the tasks with less demanding deadline
> requirements and NOHZ_FULL for tasks which aim for extreme low Tsl_max
> and Trl_max values.
> 
> There are other applications, which will need a microcontroller or a
> FPGA assisting because neither Preempt-RT nor NOHZ_FULL nor any other
> OS nor bare metal can meet their requirements due to the hardware
> immanent latencies.
> 
> There is no one fits it all solution in the variety of use
> cases.
> 
> Preempt-RT covers a large range of use cases throughout the industry,
> but I'm happy to switch to a different approach if that approach can
> handle the requirements which are handled by Preempt-RT today. To my
> knowledge neither NOHZ_FULL nor Xenomai nor bare metal fits, but I'm
> happy to be educated on that.
> 
> Thanks,
> 
> 	tglx
> 
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>