Interrupt latency performance counters

1. A computing system comprising:

an interrupt latency table comprising a plurality of entries, each of said entries being configured to store information for an interrupt processed during program execution of one or more software applications; and

an input/output (I/O) controller (IOC) comprising a plurality of interfaces;

wherein the IOC is configured to:

measure a latency for servicing a received interrupt request from one of the plurality of interfaces;

store an identification of the received interrupt request in an entry of the table;

store the measured latency in said entry of the table;

store an indication of a step of a subroutine being used to service the received interrupt request at a time that an associated latency threshold is exceeded; and

output the measured latency, in response to receiving a read access request for the measured latency.

2. The computing system as recited in claim 1 , wherein the IOC is further configured to send an indication of a long latency, in response to determining the measured latency is greater than an associated threshold.

3. The computing system as recited in claim 2 , wherein the IOC is further configured to send said indication at a time the associated threshold is exceeded.

4. The computing system as recited in claim 1 , wherein said indication begins a separate subroutine from the subroutine servicing the received interrupt request, wherein the separate subroutine is configured to reduce a time required to service the received interrupt request.

5. The computing system as recited in claim 2 , wherein the IOC is further configured to determine values based on stored latencies including at least one of the following: maximum/minimum latencies, interrupt types, and a number of interrupts exceeding associated thresholds.

6. The computing system as recited in claim 2 , wherein the IOC is further configured to store at least one of the following associated information with the measured latency: an interrupt type, an identifier of a source of the received interrupt, and identifiers of other interrupts currently being serviced.

7. The computing system as recited in claim 6 , wherein the computing system further comprises one or more processing nodes connected to a plurality of I/O devices via the plurality of interfaces, wherein the IOC is further configured to store the measured latency and associated information in software visible locations.

8. A method comprising:

maintaining in non-transitory computer accessible storage medium an interrupt latency table comprising a plurality of entries, each of said entries being configured to store information for an interrupt processed during program execution of one or more software applications;

measuring a latency for servicing a received interrupt request;

storing an identification of the received interrupt request in an entry of the table;

storing the measured latency in said entry of the table;

storing an indication of a step of a subroutine being used to service the received interrupt request at a time that an associated latency threshold is exceeded; and

outputting the measured latency, in response to receiving a read access request for the measured latency.

9. The method as recited in claim 8 , further comprising sending an indication of a long latency, in response to determining the measured latency is greater than an associated threshold.

10. The method as recited in claim 9 , further comprising sending said indication at a time the associated threshold is exceeded.

11. The method as recited in claim 8 , wherein said indication begins a separate subroutine from the subroutine servicing the received interrupt request, wherein the separate subroutine is configured to reduce a time required to service the received request.

12. The method as recited in claim 9 , further comprising determining values based on stored latencies including at least one of the following: maximum/minimum latencies, interrupt types, and a number of interrupts exceeding associated thresholds.

13. The method as recited in claim 9 , further comprising storing at least one of the following associated information with the measured latency: an interrupt type, an identifier of a source of a received interrupt, and identifiers of other interrupts currently being serviced.

14. The method as recited in claim 13 , wherein the interrupt request is from a processing node or an input/output (I/O) device, the method further comprising storing the measured latency and associated information in software visible locations.

15. An interrupt controller comprising:

an interrupt latency table comprising a plurality of entries, each of said entries being configured to store information for an interrupt processed during program execution of one or more software applications; and

an interface for receiving interrupt requests;

control logic; and

monitoring logic;

wherein the control logic is configured to:

prioritize interrupt requests received from the interface; and

send an indication to begin an interrupt service routine corresponding to a highest priority interrupt request; and

wherein the monitoring logic is configured to:

measure a latency for servicing the highest priority interrupt request;

store an identification of the received interrupt request in an entry of the table;

store the measured latency in said entry of the table;

store an indication of a step of a subroutine being used to service the received interrupt request at a time that an associated latency threshold is exceeded; and

output the measured latency, in response to receiving a read access request for the measured latency.

16. The interrupt controller as recited in claim 15 , wherein the monitoring logic is further configured to send an indication, in response to determining the measured latency is greater than an associated threshold.

17. The interrupt controller as recited in claim 16 , wherein the monitoring logic is further configured to determine values based on stored latencies including at least one of the following: maximum/minimum latencies, interrupt type, and a number of interrupts exceeding associated thresholds.

18. The interrupt controller as recited in claim 16 , wherein the monitoring logic is further configured to store at least one of the following associated information with the measured latency: an interrupt type, an identifier of a source of the received interrupt, and identifiers of other interrupts currently being serviced.