Re: Interrupt Latencies

[Thomas Gleixner <tglx@linutronix.de>]

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