Comment 34 for bug 1833322

Just for perspective on this, I've used Linux since about 1993 (originally Slackware, then Gentoo, then Ubuntu) and recall manually adding irqtune to my system in the distant past.

When irqtune was originally developed, it was common to run XT-PIC, all interrupts were went to CPU 0, period. When one turned on IO-APIC back then, interrupts still went to CPU 0 by default but could be rerouted. This was largely to be able to hit gigabit+ speeds on systems of the time.

Now? CPUs are faster, memory is faster, and the interrupt handlers are much more efficient than in the kernel of, say, 15 or 20 years ago. If you disable irqtune, you can observe in /proc/interrupts that various device interrupts are still sent to CPUs other than CPU0, they just don't go ping-ponging around between all of them like they do with irqtune. A big difference compared to the early days, for example for ethernet a lot of the work that was done in the interrupt handler back then, the interrupt handler now does the bare minimum and does the rest of the work with a kernel thread (same for wifi, which tends to be a bit of an interrupt and CPU hog.. along with SCSI/SAS/SATA/etc., NVMe, various video drivers, and I'm sure a bunch of other drivers... I'm sure there may still be some that do everything in the interrupt handler but best practice has been to do work in a worker thread for a long time and most drivers do). Meaning the actual interrupts take much less time to run now than they did then. The total CPU time of interrupt + worker thread work could still add up to more than 1 core can handle if you had, say, 10gbps ethernet (or 1gbps ethernet or wifi on a slower CPU). But the kernel threads can be scheduled to any CPU core just like any other thread even if the interrupts are tied to one CPU..