Re: a joint letter on low latency and Linux

[Paul Barton-Davis]

>We need hard-realtime from userspace. We need hard-realtime that is mostly
>safe with binary only applications. We need hard-realtime that can mostly
>be debugged, that will work with multiple 10k+ statement programs running
>at once.
>
>We dont need the superfast, edge of the hardware, performance offered by
>RTlinux.
>
>Perhaps we need two new terms:
>
>Fast-hard-realtime: Hard-realtime approaching the limitations of hardware. 
>		    This is what RTLinux supplies.
>Slow-hard-realtime: Realtime that is orders of magnatude less then what
>		    the hardware is capable. This type just requires
>		    better kernel design (i.e. no O(N^3) algos) and a tiny
>		    amount of very carefully selected preemption points.
>		    Linux should do this out of the box.

I am nervous about this characterization. As I have said many times,
"hard realtime" normally *implies* a lot more than we need for
real-time audio+MIDI applications. All we need is guaranteed
scheduling response. We don't need QOS guarantees for any other
subsystems, for example (it would be nice, but its not necessary).

Part of this is because SCHED_FIFO already offers so much. All thats
missing is the guarantee that within, oh, lets say 0.25msec of the
interrupt that makes a SCHED_FIFO thread ready to run, the thread is
running. In fact, its precisely this scheduling response that makes
other QOS guarantees hard to make. Thats fine with me.

I know that "shrinking" the list of requirements to this doesn't
actually make it much easier to implement. 

I'd like to get a bit more specific though, because the heat+light
surrounding this issue is clouding the substance of the whole thing.
I'd like to try to get some people to use the latency identifying
patch that was mentioned here yesterday, and run it enough times on
enough different systems that we can identify just where the codepaths
are that prevent good scheduling response from happening now.

Once we have them identified, we can examine each one, and figure out
if there really are hard design problems associated with it, or if it
seems truly justifiable (even on aesthetic terms) to add a preemption
point. Linus, Ingo, Andrea and others have noted that it seems OK to
add them to the uaccess stuff already.

--p