The total execution time of an interrupt handler includes:

• Hardware interrupts latency, this parameter is pretty much fixed and characteristic of the system.
• Fixed handler overhead, for example registers stacking/unstacking.
• Handler-specific code execution time, for example, in a serial driver, this is the time used by the handler to transfer data from/to the UART.
• OS overhead, any operating system requires to run some extra code in interrupt handlers in order to handle correct preemption and context switching.

The interrupt latency is the time interval from an interrupt event to the execution of the handler code. Unfortunately this time is not constant in most cases, see the following graph: In this scenario the jitter (busy state) is represented by the sum of:

• Higher or equal priority interrupt handlers execution time combined. This time can go from zero to the maximum randomly. This value can be guaranteed to be zero only if the interrupt has the highest priority in the system.
• Highest execution time among lower priority handlers. This value is zero on those architectures (Cortex-M3 for example) where interrupt handlers can be preempted by higher priority sources.
• Longest time in a kernel critical section that can delay interrupt servicing. This value is zero for fast interrupt sources which can preempt the kernel.

This is the time between an event, for example an interrupt, and the execution of the thread that will process it. Imagine the following graph as the continuation of the previous one: In this scenario all the jitter sources previously discussed are also present and there is the added jitter caused by the activity of the higher priority threads.

For each of the previously described jitter sources there are possible mitigation actions.

An obvious mitigation action is to optimize the interrupt handler code as much as possible for speed. Complex actions should never be performed in interrupt handlers, an handler should just serve the interrupt and wakeup a dedicated thread in order to handle the bulk of the work.
Another possible mitigation action is to evaluate if a specific interrupt handler really needs to interact with the OS, if the handler uses full stand-alone code then it is possible to remove the OS related overhead.

OS kernels usually protect some critical internal data structures by disabling (fully in simple architectures, to some extent in more advanced microcontrollers) the interrupt sources. Because of this the kernel itself is a jitter cause, a good OS design minimizes the jitter caused by the kernel by using adequate data structures, algorithms and coding practices. A good OS design is not the whole story, some OS primitives may generate more or less jitter depending on the system state, for example the maximum number of threads on a certain queue, the maximum number of nested mutexes and so on. Some algorithms employed internally can have constant execution time but others may have linear execution time or be even more complex.

At thread level, the response time is still affected by the interrupt-related jitter but mainly by the activity of the higher priority threads and contention on protected resources.
It is possible to improve the system overall response time and reduce jitter by carefully assigning priorities to the various threads and carefully designing mutual exclusion zones, or even better, design out mutual exclusion at all if possible. The use of the proper synchronization mechanism (semaphores, mutexes, events, messages and so on) also helps to improve the overall system performance. The use of the Priority Inheritance algorithm can improve the overall response time and reduce jitter but it is not a magic wand, a proper system design comes first.