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

[Christoph Lameter <cl@linux.com>]

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.

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

> > 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.
>
> Your industry is a total different application space. Please stop to
> project your narrow view of the application space onto everybody.

This is actually what I heard from the Dronecode people and what I
mentioned to you before in Dublin. Stop trying to make silly arguments
that the cases I discuss are just special. These attempts to kill the
discussion make it questionable if we can actually discuss this at all.
The dronecode people went to a special RTOS on a special processor because
the "realtime" offered by preempt_rt was not really realtime. They needed
hard realtime.

> The key of an RTOS is the deterministic guarantee for the time it
> takes to enqueue a given task up to the completion of the task. The
> design goal is not high throughput. The design goal is to achieve
> latency guarantees. An RTOS sacrifices performance and throughput to
> achieve that guarantees.

Indeed please lets do that. That means hard real time. And lets limit the
sacrifices as much as possible.

> Once again: The definition of Real-Time is determinism, not speed.

Yes then please do deterministic latencies. No exceptions. No soft
realtime.

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

> I'm well aware that your use case exists. It was one of the reasons
> why I started the NOHZ FULL effort in the first place. Please, fix
> your NOHZ FULL isolation problem and stop imposing your completely
> domain specific blinkerdness on everybody else.

I have no particular use case for my company in mind here. This is what I
hear when talking to various companies in a number of different areas of
computing that have tried preempt_rt.