Stop your interrupts from stealing all the CPU time
By Saket Jain Published Linux/Unix
Stop your interrupts from stealing all the CPU time
Technical Briefing | 7/20/2026
You spend all morning tuning your application code to squeeze out every drop of performance, only to find the server is still jittery under load. It looks like high CPU usage, but your application threads seem bored. That is the classic telltale sign of interrupt storms hiding in plain sight. I have seen more than one production incident where a rogue network card or a misaligned hardware interrupt turned the kernel into a full-time traffic cop, leaving your processes fighting for whatever slices are left.
Checking if the kernel is drowning in IRQs
The standard top or htop output often lumps softirq time into system time, which is misleading. You need to look at the per-CPU breakdown to see if one core is getting hammered while others sit idle. If you see softirqs spiking when you push traffic, the kernel is likely failing to balance the load across your available cores.
watch -n1 'cat /proc/softirqs'
- NET_RX is your first place to look for network saturation
- Keep an eye on the delta between columns to identify a specific bottleneck
- Compare the interrupt count against your CPU affinity settings
Forcing the kernel to share the load
If you are running on modern hardware, you should ensure smp_affinity is actually distributing the work. Too often, everything defaults to CPU 0, and that poor core becomes a bottleneck while your other 31 cores go for a smoke break. You can manually pin interrupts to specific cores by writing to the proc file, though honestly, checking if irqbalance is running and actually sane should be your first move.
If you verify the spread and still see localized spikes, look into whether your hardware supports RSS or multiqueue networking. Sometimes the fix isn’t tuning software but updating a firmware driver that was clearly written for a different era. Once you get these interrupts spread out, you’ll see your application latency settle down, and you can go back to worrying about actual code bugs instead of kernel housekeeping.
