Re: RT patch acceptance

[James Bruce]

Nick Piggin wrote:
> I have never been in any doubt as to the specific claims I have
> made. I continually have been talking about hard realtime from
> start to finish, and it appears that everyone now agrees with me
> that for hard-RT, a nanokernel solution is better or at least
> not obviously worse at this stage.

It is only better in that if you need provable hard-RT *right now*, then 
you have to use a nanokernel.  The RT patch doesn't provide guaranteed 
hard-RT yet[1], but it may in the future.  Any RT application programmer 
would rather write for a single image system than a split kernel.  So if 
it does eventually provide hard-RT, just about every new RT application 
will target it (due to it being easier to program for).  In addition it 
radically improves soft-RT performance *now*, which a nanokernel doesn't 
help with at all.  "Best" would be getting preempt-RT to become 
guaranteed hard-RT, or if that proves impossible, to have a nanokernel 
in addition to preempt-RT's good statistical soft-RT guarantees.

I think where we violently disagree is that in your earlier posts you 
seemed to imply that a nanokernel hard-RT solution obviates the need for 
something like preempt-RT.  That is not the case at all, and at the 
moment they are quite orthogonal.  In the future they may not be 
orthogonal, because *if* preempt-RT patch becomes guaranteed hard-RT, it 
would pretty much relegate nanokernels to only those applications 
requiring formal verification.

 - Jim Bruce

P.S. Preempt-RT is a sight to behold while updatedb is running.  The 
difference between it and ordinary preempt is quite impressive.  Nothing 
currently running has so much as a hiccup, even though / is using the 
non-latency-friendly ReiserFS.  The only way I even notice updatedb is 
running at all is through my CPU monitor and the fact that disk IO is 
slower.

[1] By this I mean on a system loaded with low priority tasks doing the 
relatively arbitrary things one might do on a live system.
-
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/