Re: [RFC][PATCH] Restricted hard realtime

[Andrew Morton <akpm@osdl.org>]

Karim Yaghmour <karim@opersys.com> wrote:
>
> Here are a number of solutions that some have found to be "correct"
>  for their needs over time, in chronological order of appearance:
>  a- Master/slave kernel (ex.: RTLinux)
>  b- Dual-CPU (there are actually many examples of this, some that
>      date back quite a few years)
>  c- Interrupt levels (ex.: D.Schleef, B.Kuhn, etc.)
>  d- Nanokernel/Hypervisor (ex.:Adeos)
>  e- Preemption
>  f- Uber-preemption and IRQ threading (a.k.a. preemption on acid)
>      (ex.: Ingo, TimeSys, MontaVista, Bill)

uber-preemption is the chosen way for the mainline kernel mainly because
its mechanisms can be largely hidden inside (increasingly ghastly) header
files and most developers just don't have to worry about it.

I have a sneaking suspicion that the day will come when we get nice
sub-femtosecond latencies in all the trivial benchmarks but it turns out
that the realtime processes won't be able to *do* anything useful because
whenever they perform syscalls, those syscalls end up taking long-held
locks.

Which does lead me to suggest that we need to identify the target
application areas for Ingo's current work and confirm that those
applications are seeing the results which they require.  Empirical results
from the field do seem to indicate success, but I doubt if they're
sufficiently comprehensive.