Read Per-CPU Interrupt Counts from /proc/interrupts

You will learn to read the live interrupt counters exposed by Linux, identify which CPU is servicing a device, and compare two samples without mistaking a large lifetime counter for a current fault. You need a shell on the Linux host. The commands are read-only and normally need no elevated privileges. Allow about 10 minutes for a first inspection.

What this file tells you

/proc/interrupts records interrupt counts for each CPU and I/O device. It also includes internal kernel interrupt categories. On x86 and x86-64, the manpage specifically calls out entries such as NMI, the local timer, TLB flushes, rescheduling and remote function calls. The file is generated by procfs, so it is a current kernel view rather than a report saved on disk.

The counters are cumulative. A large value means that many interrupts have been handled since the relevant counter started, not that the device is currently consuming that much CPU. To discuss activity, take two readings separated by a known interval and compare the change.

1. Read the table

Print the file exactly as the kernel presents it:

cat /proc/interrupts

On a multi-CPU machine, the first line names the CPU columns. A numbered line begins with an IRQ identifier followed by one count per CPU, then kernel routing details and a device label. The labels and routing text vary by kernel, firmware, virtual machine and drivers, so do not write a parser that assumes a particular number of trailing fields.

You may also see unnumbered names such as NMI, LOC, RES, CAL and TLB. These are not ordinary device IRQ numbers. They describe classes of interrupts internal to the system. A line containing zeroes is still useful: it shows that the category exists on this kernel but has not accumulated a count.

2. Find a device without losing its CPU distribution

Search for a stable device label, keeping the header for context. Replace DEVICE with a label visible in your own output:

grep -E 'CPU|DEVICE' /proc/interrupts

For example, this keeps the header and any line containing xhci, a common USB host-controller label:

grep -E 'CPU|xhci' /proc/interrupts

Read the counts horizontally. If one CPU has nearly all of a device's interrupts, that is a distribution observation, not proof of a problem. IRQ affinity, the driver, workload and the host's interrupt-balancing policy can all affect it. First establish whether the count is increasing quickly, and whether the same CPU is busy for another reason.

Do not use a guessed IRQ number from another machine. IRQ assignments can change after a reboot, hardware change or virtualisation configuration. Use the current label and current output.

3. Compare two snapshots

Take a first sample, wait briefly, then take a second. This pipeline prints the matching device lines at each point:

grep -E 'CPU|xhci' /proc/interrupts
sleep 5
grep -E 'CPU|xhci' /proc/interrupts

The second reading should have counters at least as large as the first while the system continues running. Subtract the first per-CPU row from the second to get interrupts handled during the five-second interval. A row that does not change may simply represent an idle device. A rapidly changing row deserves correlation with workload, CPU utilisation and logs before you change any configuration.

For a quick view of numbered IRQ totals, this command sums only the initial numeric fields after the IRQ label. It is deliberately a rough inspection tool, not a universal parser:

awk 'NR > 1 && $1 ~ /^[0-9]+:$/ { total = 0; for (i = 2; i <= NF; i++) if ($i ~ /^[0-9]+$/) total += $i; print $1, total }' /proc/interrupts

It works with the table shown by this host because the per-CPU counts are numeric and the routing fields are not. If a kernel presents additional numeric fields, the result can include them. For a precise device investigation, inspect the original row instead of treating this total as authoritative.

4. Handle misleading or missing readings

Seeing no output is not automatically evidence that the machine has no interrupts. Procfs may be restricted by a container, a different process namespace or the environment in which the command runs. Compare the command's environment with the host you intend to diagnose. The installed file is read-only, and changing its mode or trying to write to it will not configure interrupt handling.

Do not infer a hardware failure from a high NMI, LOC, RES, CAL or TLB value alone. These counters are lifetime totals and can be high on a busy, long-running system. Compare rates and corroborate with the device's behaviour. Conversely, a low device count does not prove that the device is healthy: an idle device may be functioning normally, and an interrupt may be only one part of a larger driver path.

This guide does not change IRQ affinity, disable an interrupt or restart a service. Those actions can affect all users of a device and require separate evidence and a recovery plan. If you later test a configuration change, save the current setting first, make one reversible change, and verify the result with another pair of snapshots.

Done means

• You can display /proc/interrupts and identify its CPU columns.
• You can distinguish numbered device rows from named internal interrupt categories.
• You can find the current row for a device instead of assuming an IRQ number.
• You can compare two readings over a measured interval and discuss a rate.
• You have kept observation separate from risky changes to interrupt routing or services.