Messages in this thread | | | Date | Fri, 10 Jun 2005 17:48:07 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Attempted summary of "RT patch acceptance" thread |
| |
On Fri, Jun 10, 2005 at 07:37:28PM +0200, Andrea Arcangeli wrote: > Hello Paul, > > kudos for your very nice RT documents (as usual ;)
Thank you, glad you liked it!
> On Fri, Jun 10, 2005 at 08:47:46AM -0700, Paul E. McKenney wrote: > > Good point -- I certainly need to add a disclaimer to the effect that > > common hardware (such as VGA, last I checked some months ago) can > > > a. Quality of service: soft realtime, with timeframe of 100s of > > microseconds for task scheduling and interrupt handling, but > > -only- for very carefully restricted hardware configurations > > that exclude problematic devices and drivers (such as VGA) > > that can cause latency bumps of tens or even hundreds of > > milliseconds (-not- microseconds). Furthermore, the software > > configuration of such systems must be carefully controlled, > > for example, doing a "kill -1" traverses the entire task list > > with tasklist_lock held (see kill_something_info()), which might > > result in disappointing latencies in systems with very large > > numbers of tasks. System services providing I/O, networking, > > task creation, and VM manipulation can take much longer. A very > > small performance penalty is exacted, since spinlocks and RCU > > must suppress preemption. > > > > Does this help, or are there other CONFIG_PREEMPT latency issues that > > need to be called out? > > You don't need to add it to the document, but as a further pratical > example of troublesome hardware besides VGA (could be a software issue > and not hardware issue though) I'd like to make the example of the irq > handler of the uhci usb1.1 controller that takes up to 8msec on a 1ghz > atlhon UP system, and there's nothing that PREEMPT can do about it since > it's an hard-irq. This latency keeps triggering a few times per second > on my firewall for the last few years.
After reading the ensuing thread, I am not sure what example to use! Maybe I should just pick random examples and see if they tend to get fixed? ;-)
> preempt-RT _can_ do something about it but only _if_ people hacks the > drivers properly and makes sure to call local_irq_save_nort instead of > local_irq_save and other explicit changes like that, things that if > missing are noticeable only during measurements with preempt-RT config > option enabled (hence the metal-hard classification of preempt-RT and > not ruby-hard definition). > > 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: > > --- linux/drivers/net/tg3.c.orig > +++ linux/drivers/net/tg3.c > @@ -3229,9 +3229,9 @@ static int tg3_start_xmit(struct sk_buff > * So we really do need to disable interrupts when taking > * tx_lock here. > */ > - local_irq_save(flags); > + local_irq_save_nort(flags); > if (!spin_trylock(&tp->tx_lock)) { > - local_irq_restore(flags); > + local_irq_restore_nort(flags); > return NETDEV_TX_LOCKED; > } > > There's no apparent reason why all those changes should be required to > get hard-RT. > > 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. > > 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: > > http://linuxdevices.com/articles/AT7871136191.html > > In the above RTAI should have made it as well as rtlinux of course.
As long as the nested-OS or migration-between-OSes approaches prevents Linux from disabling interrupts, then interrupts and preemption-disabling are not a problem. As noted later in this thread, there is still the possibility of hardware stalls, which seems to affect all the approaches, with the possible exception of migration-within-OS between CPUs that don't share the offending hardware. Maybe a dual AMD?
Thanx, Paul - 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/
| |