linux-kernel - Interrupt Latencies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Feb 2011 10:35:02 +0100
From:	"Schaefer Dr, Frank-Rene ()" <fschaef9@...teon.com>
To:	<linux-kernel@...r.kernel.org>
Subject: Interrupt Latencies

Hello. 

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(...);

However, the difference in latency to "request_irq(...)" 
is not measurable. It is still in the range from 60 to 110us
on a 1.6 GHz Atom CPU. From "linux/interrupt.h" I conclude 
that depending on 

           CONFIG_GENERIC_HARDIQS

either 'request_irq' is mapped to 'request_threaded_irq' 
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 
is totally incomprehensible to me why the 'quick_check_handler' 
must have a latency of 60us at min. (that are many thousand 
instructions).

Any help and comments are greatly appreciated.

Best Regards

Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/