Understanding IRQ Handling in Linux

Interrupt Requests (IRQ) are calls that devices can make to request special attention from the processor.

Most computers only offer 16 hardware interrupts. This may seem small for modern configurations with many different devices. Fortunately, IRQs can be shared.

The interrupt handling mechanism causes the CPU to be attentive to external events in the sequence of instructions it is executing, for when a break in the normal processing is needed to attend to another request.

In large multi-user systems, a constant burst of interrupts is directed to the processor.

Fast responses to these interrupts are essential to keep system resources well utilized, and to provide acceptable response times for users.

It is important to know that these resources are limited and need to be managed to avoid conflicts between devices.

Thus, operating systems react to events that represent service requests.

For example, if an application needs to read a file, it makes a request to a function executed by the operating system.

This will access the device controller and request the transfer of data to the memory address provided in the service request.

When the device controller finishes, it notifies the processor through an interrupt request that will cause the operating system to execute a routine to handle it.

Interrupts can be generated by the following events:

• Generated by program, implemented using special instructions;
• By error, such as division by zero, memory reference outside the allowed space, etc;
• By time, such as in scheduling;
• Hardware failure;
• By input and output data events signaling the end of operation or error condition.
• So, the events generated by interrupts cause the execution of the handler routine corresponding to the interrupt source in the operating system.

When handling hardware interrupts, the requesting device interrupts the processor.

It finishes executing the current instruction, tests for the existence of an interrupt, and saves the current state of the process that will lose control of the processor in memory.

The processor loads the program counter with the address of the interrupt handler routine and transfers control to the interrupt handler routine.

The interrupt handler routine executes and, upon completion, restores the previous state to return to execution of the interrupted routine.

A simple kernel disables interrupt handling while it responds to an interrupt. They are re-enabled after processing is complete.

If there is a constant flow of interrupts, as in multi-user systems, this scheme can cause interrupts to be disabled for a long time and result in unsatisfactory responses.

To avoid this, the Kernel needs to be aware of the maximum processing time allowed for each interrupt. If this time slice is exceeded, it passes the remaining interrupt processing to another appropriate system process that will finish handling them, while the kernel remains able to receive new interrupts.

This means interrupts can remain enabled for a long time, and the system becomes more efficient in responding to user application requests.

The system's IRQ list can be seen in the file

# cat /proc/interrupts 

           CPU0       

  0:         78   IO-APIC   2-edge      timer

  1:          9  xen-pirq   1-ioapic-edge  i8042

  4:       3409  xen-pirq   4-ioapic-edge

  8:          2  xen-pirq   8-ioapic-edge  rtc0

  9:          0  xen-pirq   9-ioapic-level  acpi

 12:          3  xen-pirq  12-ioapic-edge  i8042

 14:          0   IO-APIC  14-edge      ata_piix

 15:          0   IO-APIC  15-edge      ata_piix

 48:   14474493  xen-percpu-virq      timer0

 49:          0  xen-percpu-ipi       resched0

 50:          0  xen-percpu-ipi       callfunc0

 51:          0  xen-percpu-virq      debug0

 52:          0  xen-percpu-ipi       callfuncsingle0

 53:          0  xen-percpu-ipi       spinlock0

 54:        211   xen-dyn-event     xenbus

 55:     755401   xen-dyn-event     blkif

 56:     887240   xen-dyn-event     eth0

NMI:          0   Non-maskable interrupts

LOC:          0   Local timer interrupts

SPU:          0   Spurious interrupts

PMI:          0   Performance monitoring interrupts

IWI:          0   IRQ work interrupts

RTR:          0   APIC ICR read retries

RES:          0   Rescheduling interrupts

CAL:          0   Function call interrupts

TLB:          0   TLB shootdowns

TRM:          0   Thermal event interrupts

THR:          0   Threshold APIC interrupts

DFR:          0   Deferred Error APIC interrupts

MCE:          0   Machine check exceptions

MCP:       1216   Machine check polls

HYP:   16105716   Hypervisor callback interrupts

ERR:          0

MIS:          0

PIN:          0   Posted-interrupt notification event

PIW:          0   Posted-interrupt wakeup event

Want to learn more about Linux? Check out our course for the LPI exam

Learn much more about Linux in our online course. You can enroll here with a 7-day free trial. If you already have an account, you can access it here.

Liked it? Share :-)