Re: RT patch acceptance

[Esben Nielsen]

On Tue, 31 May 2005, James Bruce wrote:

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

What do you mean by "provable"? Security critical? Forget about
nanokernels then. The WHOLE system has to be validated. If you want to a
system good enough to put (a lot of) money on it: Test, test, test.

I can't see it would be easier prove that a nano-kernel with various
needed mutex and queuing mechanism works correct than it is to prove that
the Linux scheduler with mutex and queueing mechanisms works correctly.
Both systems does the same thing and is most likely based on the same
principles!
If a module in Linux disables interrupts for a non-deterministic amount
of time, it destroys the RT in both scenarious. With the nanokernel, 
the Linux kernel is patched not to disable interrupts, but if someone
didn't use the official local_irq_disable() macro the patch didn't work
anyway...
The only way you can be absolutely sure Linux doesn't hurt RT is to run
it in a full blown virtuel machine where it doesn't have access to disable
interrupts and otherwise interfere with the nano-kernel.

> 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 it is nearly there. A few things needs to be revisited and a lot
of code paths you would have liked to use isn't RT (ioctl forinstance
still hits BKL :-( ).

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

And I state that for those applications the nanokernel isn't good enough,
either. Otherwise I completely agree with you. 
The nanokernel does have one thing PREEMPT_RT doesn't: Very short
latencies. To cap the interrupt latencies in Linux even further some
tricks will have to be made - and these would hurt performance. These
tricks are more or less what a nanokernel does: Running the whole of
Linux, including the scheduler, and all regions protected with raw
spinlocks with interrupts fully enabled.

Esben

> 
>   - Jim Bruce
> 

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