Re: Attempted summary of "RT patch acceptance" thread

[hui]

On Fri, Jun 10, 2005 at 07:37:28PM +0200, Andrea Arcangeli wrote:
> See the tg3 updates required to be safe with preempt-RT without breaking
> hard-RT as a clear example of how preempt-RT is weak:
...
> There's no apparent reason why all those changes should be required to
> get hard-RT.

Some of it is lack of displine with how various drivers do locking in
that they overload the meaning of a spin_lock, etc... to also disable
preemption and side effects with preempt_count. Making all of this formal
is a good thing since it clarifies and un-ambiguates those code paths.
It's something that should have been done in the first place and I
consider using implicit masking like that to be rather sloppy.

> Both RTAI and rtlinux _don't_ require to change all those drivers to get
> the guarantee that the kernel will get out of the way within a certain
> nanoseconds deadline interval.

They obey the same constraints on driver in those nanokernel systems also
apply to the preempt patch. There is no difference other than the regular
driver layers in that they now need to be audited, duh. All RTOSs need to
do this.

> Furthermore with the scheduler, mutex and context switch code into the
> equation, it gets more and more difficult to calculate with math the max
> latency that preempt-RT will provide, while it's almost trivial to do
> that with RTAI/rtlinux given only the nanokernel code runs before the
> hard-RT code is invoked and there are not many paths to test, so one has
> to disable the cache and just measure the few possible nanokenrel paths.
> (as usual when speaking about hard-RT I've robots in mind, and not audio
> code that will call into the alsa ioctls)
> 
> This below is the kind of stuff where I wouldn't even dream to replace
> a ruby-hard rtlinux/RTAI with a weaker metal-hard and possibly
> underperformant (cause scheduling hard-irq in userland and scheduling
> instead of spinning isn't going to be cheap in smp) preempt-RT solution:

LynxOS is a hard real time OS similar to how the preemption patch works
in that it's a single kernel system. It's gets those times regularly and
is obviously deterministic because of careful coding conventions just like
it has always been. Single kernel determinism is not new. It's only new
to you.

bill

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