Interrupt Latencies (Windows Embedded CE 6.0)
1/6/2010
One of the most important aspects of kernel real-time performance is the ability to service an interrupt request (IRQ) within a specified amount of time. Interrupt latency refers primarily to the software interrupt handling latencies; that is, the amount of time that elapses from the time that an external interrupt arrives at the processor until the time that the interrupt processing begins. If paging does not occur, Windows Embedded CE interrupt latency times are bounded for threads locked in memory. This makes it possible to test for the worst-case latencies: the total times to the start of the interrupt service routine (ISR) and to the start of the interrupt service thread (IST). The total amount of time until the interrupt is handled can then be determined by calculating the amount of time needed within the ISR and IST.
The servicing of an IRQ in Windows Embedded CE begins with the kernel, which traps all exceptions and then determines the appropriate action. In the case of an IRQ, the kernel traps the IRQ, saves the registers supported for the ISR, and calls the ISR you specified. The saving and restoring of registers is required to support nested interrupts. Because the time delay from IRQ to ISR is bounded, the only way to affect this delay is to turn off interrupts, which the kernel does periodically for a limited time.
ISR latency is the interval that begins when an IRQ is set in the CPU and ends when the ISR begins to run. The start of the ISR that is being measured can be calculated based on the current status of other interrupts in the system. If an interrupt is in progress, calculating the start of the new ISR to be measured must account for two factors: the number of higher-priority interrupts that will occur after the interrupt of interest has occurred and the amount of time spent executing an ISR.
At the ISR level, you can perform limited functionality. The ISR runs in a special context in which memory is characterized as statically mapped virtual addresses. That is, the OEM specially maps the physical addresses used by an ISR. There is no access to any of the Microsoft Win32® APIs and only one way to signal another thread. This prevents the OEM from performing tasks in the ISR that can adversely affect the real-time capabilities of the OS. However, even with this limitation, the OEM should always be concerned with the amount of time spent in the ISR. The longer the time spent in the ISR, the longer it will take to call the IST, should further processing be required. All of the work required to service the interrupt should be completed in the ISR, if the time required is minimal and if it does not influence the rest of the system. As long as an ISR is running, no threads will be scheduled in the system. The OS supports nested interrupts based on the hardware's support for this functionality, and will nest interrupts based on their priority, which is determined by the hardware or the OEM.
IST latency is the interval that begins when an ISR finishes execution and signals a thread, and ends when the IST begins execution. The start time of the highest-priority IST begins after all ISRs have returned to the kernel and the kernel has performed some amount of work to begin the execution of the IST. The IST start time is affected by the total time spent in all ISRs after the ISR returns and signals the IST to run. Windows Embedded CE adds a restriction to ISTs: The event handle that links the ISR and IST can only be used in the WaitForSingleObject function. Windows Embedded CE prevents this event handle from being used in a WaitForMultipleObjects function. This means that the kernel can guarantee an upper bound on the time to trigger the event and time to release the IST.
There are several factors that can interrupt latencies, some of which are controlled by the OEM and others by the kernel. The kernel can affect interrupt latencies in the following ways:
- Interrupts can be turned off.
- On the return from an ISR, a portion of the kernel that cannot be preempted might need to complete before information returned from the ISR is acted upon or before the highest-priority thread can be scheduled.
An OEM can affect real-time performance by doing the following:
- Turning off interrupts.
- Spending too much time processing an ISR.