Re: RT patch acceptance

[James Bruce <bruce@andrew.cmu.edu>]

Lee Revell wrote:
> Since *everything* is preemptible except a few known code paths whose
> execution times determine the maximum possible latency from interrupt
> to running the highest priority user process.

Have all the code paths been audited?  If there's a reference to an 
analysis that's been done, please pass it on as I'd like to read it. 
Remember that it must take into account completely cold L1 and L2 caches 
for almost all of the computation, or its not truly a worst-case 
analysis.  If this has been done, I stand corrected.  If not, then 
there's no proven maximum latency, just statistical arguments that it 
works well.  Keep in mind that such an argument can be good enough for 
most of the RT stuff people are doing, but I'm not putting my hand under 
the saw just yet :)

> That's the determinism, no more, no less.  But some people
> inexplicably think this thread is about providing deterministic hard
> RT performance for some subset of system calls, or disk IO or
> something, none of which have anything to do with PREEMPT_RT.

Well, that's the direction people want to take it in, since an RT thread 
unable to receive any type of input or produce some type of output isn't 
particularly useful for anything.  First steps first, of course.

I really think the RT patches are great in what they achieve, but true 
hard realtime does require proof, and I'm not aware of that having been 
done (yet).  However that's not a prerequisite for usefulness; A 
measurement of 5 or 7 nines of reliability getting sub 100us latency 
will certainly make most application writers happy.

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