Messages in this thread | | | Date | Fri, 10 Jun 2005 12:39:26 -0700 | Subject | Re: Attempted summary of "RT patch acceptance" thread | From | Bill Huey (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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |