Messages in this thread | | | Subject | RE: Interrupt Latencies | Date | Tue, 22 Feb 2011 17:10:20 +0100 | From | "Schaefer Dr, Frank-Rene ()" <> |
| |
We are using GPIO pins and map them to IRQ. The underlying driver seems to use message signaled interrupts.
-----Original Message----- From: Thomas Gleixner [mailto:tglx@linutronix.de] Sent: Tuesday, February 22, 2011 3:39 PM To: Schaefer Dr, Frank-Rene () Cc: linux-kernel@vger.kernel.org Subject: Re: Interrupt Latencies
On Tue, 22 Feb 2011, Schaefer Dr, Frank-Rene () wrote: > Having read "Moving interrupts to threads" at > > http://lwn.net/Articles/302043/ > > I expected to reduce interrupt latency during a SPI > communication by handling the transmit-receive in a > 'quick_check_handler' using > > request_threaded_irq(...);
The quick check handler has the same latencies as the normal handler of an interrupt requested by request_irq. Interrupt latency depends on various factors:
- Interrupt disabled code regions - Concurrent interrupts and the ordering of handling - Deep idle states - Bus contention - Cache misses
The maximum latency is the worst case of all the above added together.
> or vice versa. We are able to measure the latency precisely > as the difference of the time when the interrupt pin 'IN' > is raised and we raise our response pin 'OUT' as shown below. > > pin IN .------------------------- > ______________| > > pin OUT .----------- > ____________________________| > > |<- latency ->| > > Could anyone point to locations in the kernel so that I can > precisely understand the mechanisms that cause the latency? It
There is no single mechanism.
> is totally incomprehensible to me why the 'quick_check_handler' > must have a latency of 60us at min. (that are many thousand > instructions).
How is that interrupt connected to the CPU/chipset? Which driver(s) is/are involved ? How is the pin OUT accessed from the driver?
Thanks,
tglx
| |