Calculate hardware interrupt rate per second and its CPU overhead impact.
/proc/interrupts exposes cumulative interrupt counts per IRQ line per CPU since boot; sampling it twice and dividing the delta by the elapsed time gives interrupts per second, the standard way tools like `vmstat` (in) and `mpstat` (%irq/%soft) derive their interrupt-rate metrics. Multiplying that rate by average handler execution time estimates the CPU time consumed purely by interrupt handling — usually negligible, but on high-throughput network or storage systems with poor IRQ distribution across cores, this overhead can become a measurable and unevenly-distributed tax on available CPU capacity.
Interrupt rate and overhead
interrupts_per_sec = (count_t1 − count_t0) / interval; overhead = interrupts_per_sec × handler_time
/proc/interrupts reports a cumulative counter since boot, not a rate — a single reading just tells you the total historical count. Rate requires sampling the counter at two points in time and dividing the difference by the elapsed interval, the same approach `vmstat 1` uses internally for its 'in' (interrupts/sec) column.
Hardware interrupts (IRQs) are raised directly by devices and handled with minimal, fast top-half handlers; much of the actual processing work is deferred to softirqs (bottom halves) or threaded IRQ handlers, which run later at a lower priority. `mpstat`'s %irq and %soft columns report these separately, and high %soft often indicates network packet processing (NET_RX/NET_TX softirqs) load.
Check /proc/interrupts per-CPU columns to see if one core is handling disproportionately many interrupts for a given IRQ, then use `irqbalance` (usually running by default) or manually set /proc/irq/<N>/smp_affinity to distribute a busy device's interrupts (e.g. a multi-queue NIC) across more cores.