What happens when two interrupts occur at the same time in linux kernel

Question

What happens when two interrupts occur at the same time in the Linux kernel..?

If that processor has more than one CPU can the interrupts run on different cpu cores at the same time.

Answer 1

There is always a hierarchy of interrupt signals. The highest priority one is the first seen by the CPU and acted upon. Once that is done, the then next highest priority interrupt is handled. It is possible that a third interrupt signal of higher priority than the first two has arrived since, so it will be handled out of order, which is the point of priority.

Linux has support for interrupt affinity so that one IRQ is always routed to a particular CPU or group of CPUs. Poke around in /proc/interrupts.

Answer 2

When a processor responds to an interrupt, certain sensitive phases of the interrupt processing are protected from interruption by another interrupt. In general, though, the execution of the bulk of an interrupt handler is itself interruptible, meaning that the execution of the handler can be suspended in order to take another interrupt, whose handler has to run to completion (return) before the original handler can be restarted: the interrupts nest.

Usually there is a priority scheme in place: certain interrupts can interrupt the handlers of certain other interrupts, whereas others are blocked. (Historically, there have been many schemes: from fixed numeric priorities, to completely flexible masks.) Usually it makes sense to block the same interrupt while its own handler is executing; but that doesn't work in some situations (such as a a physical interrupt line or interrupt number being shared among multiple devices).

When two interrupt requests are raised at the same time, and both are unmasked, a given processor can only respond to one of them. Historically, this is dealt with by some piece of hardware (perhaps called an "interrupt controller") which multiplexes the interrupt lines and makes a decision about which interrupt gets through, based on some priority scheme (perhaps programmable, or else fixed). Two interrupts cannot be serviced at the same time: at least some key portion of the actions of servicing an interrupt is necessarily serialized: the portion when the CPU acknowledges the interrupt and dispatches a handler. At some point, the CPU can be made ready to handle the other interrupt which has remained pending.

In some real-time operating systems, interrupts are assigned to real-time threads. When an interrupt is received, the kernel dispatches the thread which corresponds to that interrupt; the thread then services it. As soon as the thread is dispatched, the system is ready to field the next interrupt, which will dispatch another thread and so on. The threads are prioritized, so if a higher priority interrupt dispatches a higher priority thread, it will pre-empt a lower priority interrupt's lower-priority thread. In this kind of system, interrupts are still not being processed at the same time if there is only one processor: it's just preemptive multitasking.

With multiple processors or cores, there can be interrupt service routines executing independently on the different cores. Certain interrupts can only execute on particular cores, because they pertain to the core: for instance, an interrupt which tells a processor that it has an important message from another processor, or something generated completely locally, such as a local programmable-interrupt timer which is tied to a particular core. Device-specific interrupts can be programmed to go to a particular CPU or to be somehow directed to an arbitrary CPU. This is all very hardware-specific: the details depend on how a system is designed. There could be a system in which all external interrupts are tied to one particular processor at the hardware level and Linux can support such a system.