On Tue, May 15, 2012 at 01:33:12PM -0400, Steven Rostedt wrote: > On Wed, 2012-05-09 at 23:18 +0000, Grant Edwards wrote: > > > I eventually figured out that my increased interrupt latency is due to > > my ISR being run in a kernel thread instead of as a real ISR. Adding > > the IRQF_NODELAY flag gets me the same average latency I had without > > the RT patch. [It looks like that flag has a different name in 2.6.39 > > and later?] > > Note, adding a IRQF_NODELAY is very dangerous. To keep the kernel > fully preemptible (well mostly), spin-locks have been converted into > mutexes. If the irq handler has one of these spinlocks that have been > converted, it may schedule in the interrupt handler and crash the > kernel. You can not schedule in interrupt context, which is why the > RT kernel makes the interrupt handlers into threads. Noted. Since the IRQF_NODELAY approach still misses the deadline 2-3% of the time, that approach is probably off the list anyway. Right now we're looking at using either FIQ interrupt or Xenomai. > Also note, you may get better response if you up the interrupt > thread's priority. Up it to 98, and you should see much better > responses. Thanks for the tip. I'll keep that in mind for some other projects that would need latency times in the 100-200us range, which should be doable. > Now I don't think you will make the 20us under load, but you won't do > that in the non-RT patch either. Right. With the non-RT patch, the average response is about the same, but the worst-case numbers are 2X-3X. -- Grant -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
