[Ksummit-discuss] [TECH TOPIC] Mainlining PREEMPT_RT
Thomas Gleixner
tglx at linutronix.de
Thu Oct 15 20:37:14 UTC 2015
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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
More information about the Ksummit-discuss
mailing list