Re: [RFC][PATCH] Restricted hard realtime

[Karim Yaghmour]

Andrew Morton wrote:
> 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.

Yet, this justification applies readily to the nanokernel approach. The
interrupt pipeline needed by Adeos, for example, is mostly hidden inside
headers and developers have even less to care about it then the increased
concurrency from the uber-preemption patches.

As for how useful the uber-preemption will be, there does not seem to be
any concenssus.
This is your take:
> 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.

This is Ingo's take:
> also, RT applications rarely hit the really complex kernel subsystems
> because 'complex' often means 'has the potential for IO' - on any
> hard-RT OS. 

And this is Bill's take:
> The biggest groups of folks I can identify is the multimedia folks.
> Their applications are the most system loaded out of all of the
> applications on this planet, deterministic latency, heavy CPU usage,
> heavy disk load and manical temporal control via frame schedulers, etc...
>
> This stuff has direct application to DVRs (digital video recorders)
> and other things that only SGI and BeOS machines could do in their
> day.

In the 3 replies I got, there were 3 different interpretations of how
uber-preemption will be useful:
1- It's good for latency, but apps won't really get much out of it
   because of non-deterministic syscalls.
2- Non-deterministic syscalls aren't a problem as long as they don't
   hit complex subsystems.
3- End-applications that interact with many subsystems, especially
   I/O is exactly where we want to go.

It appears that different parties draw the line at different places,
and if we follow this to its logical conclusion, it brings us to the
first choice I was highlighting:
> a) Most current kernel developers intend to eventually convert the
> entire existing code-base into one that contains deterministic
> code paths only, and therefore impose such constraints on all future
> contributors, in which case the path to follow is the one set by
> the uber-preemption folks; 

IOW, those who need deterministic response times in Linux are unlikely
to be entirely satisfied with uber-preemption, and will want more.
If I read Ingo correctly, greater determinism will come over time as
Linux is made better for SMP systems, and I somewhat agree with this.
However, reduced latencies and increased threading does not in itself
make an OS deterministic in its behavior. For those who really need
a deterministic OS, uber-preemption is therefore but a stepping stone,
and more is likely to be asked for. Yet, more will not be possible
unless there is a change in the kernel's development philosophy (at
least, that's what I can make of it).

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

Usually one of the litmus tests for this is to hook a function
generator to the system and inject a square wave through an
interrupt-generating I/O (ex.: parallel port), while measuring the
response time of an interrupt service routine and comparing it to
the input wave using an oscilloscope. One sign that the system is
indeed deterministic is that both square waves should appear
steady regardless of the load.

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@xxxxxxxxxxx || 1-866-677-4546

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/