Treatment of IRQs on Linux
Interrupt Requests (IRQ) are calls that devices can make to require special attention from the processor.
Most computers only offer 16 hardware interrupts. It may not seem like much for modern configurations with the most different devices. Fortunately, IRQs can be shared.
The interrupt treatment mechanism makes the CPU: be aware of events external to the sequence of instructions it is in executing, for when a break from normal processing is necessary for fulfill another request.
In large multi-user systems, a constant burst of interruptions is directed at the processor.
Prompt responses to these interruptions are essential to keep system resources well used, and to provide acceptable response times for users.
It is important to know that these resources are limited and need to be managed so that conflicts between devices be avoided.
In this way, operating systems react to events that represent service requests.
For example, if an application needs to read a file, it requests a function performed by the operating system.
It will access the peripheral controller and request the transfer of the data to the memory address provided in the service request.
When finished, the peripheral controller notifies the processor through an interrupt request that will cause the operating system to execute a routine for its treatment.
Interrupts can be generated by following events:
- Generated by programs that are implemented using special instructions;
- By mistake, such as division by zero, reference to memory outside the allowed space, etc.;
- By time, such as when scaling;
- Hardware failure;
- By data entry and exit events signaling the end of operation or error condition.
- Then, the events generated by the interrupts cause the execution of the treatment routine corresponding to the source of the interrupt in the operating system.
When handling hardware interrupts, the requesting device interrupts the processor.
This terminates the execution of the current instruction, tests the existence of interruptions, 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 treatment routine and transfers its control to the interruption treatment routine.
The interrupt treatment routine executes and, at the end, restores the previous state to return to the execution of the interrupted routine.
A simple core disables interrupt handling while it responds to an interruption. They are enabled again after processing be complete.
If there is a permanent flow of interrupts, such as in multi-user systems, this scheme may result in interruptions that are 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 interruption. If that time chunk breaks, it passes the rest of the interrupt processing to another appropriate system process that will finish handling them, while the core remains able to receive new interrupts.
This means that they can be enabled for a long time, and the system becomes more efficient in responding to user application requests.
The list of system IRQs can be viewed in the file
# cat /proc/interrupts
CPU0
: 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: & nbsp; 0 xen-percpu-virq debug0
52:0 xen-percpu-ipi callfuncsingle0
53:0 xen-percpu-ipi spinlock0
54: 211 xen-dyn-event xenbus
55:75401 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
Do you want to learn more about Linux? Discover our LPI exam course
Learn much more about Linux in our online course. You can enroll here with a free 7-day trial. If you already have an account, you can log in here.