Does it seem correct to say that the general intention of irqbalance wrt to system performance is to improve throughput (translating in some cases to a more responsive system) at a cost of increased processing latency? If so, then it should be considered and tuned generally with regards to usage scenarios that consider latency vs throughput. Eg digital audio workstations and gaming machines might disable it. But as Steve says, we don't have any data on the tradeoffs. How much more throughput/responsiveness for what cost in latency under what configurations? All I can find is a recommendation not to use it on CPUs with 2 or fewer cores as the overhead is said to be too high (which acc to above would translate to "unreasonable amount of latency for relatively little or even no throughput gains"), but even then, are we talking physical or logical/virtual cores? It seems like the more cores a system has, the more trivial the overhead from running irqbalance per performance/responsiveness gain. Is there a threshold number of cores beyond which something like IRQ balance becomes strongly recommended for general computing applications? But even then just like power scaling I can imagine it might still add undesirable or even critical latency in applications that are highly latency sensitive (eg when milliseconds or fractions of milliseconds matter) This website gave me some clarity on the theory and purpose: https://www.baeldung.com/linux/irqbalance-modern-hardware There is another dimension, one related to one of the reasons why Apple became known as the "AV professional's workstation" for so long, is that (apparently for fascinating reasons of a historical accident) the multimedia system engineers gained enough influence in the company to allow them to tune the default system configuration to prioritize latency and then system responsiveness over throughput (and even some compromises in system security) to allow for minimal system config in applications requiring both low and consistent (eg low jitter) latency. As it turned out, they got away with doing this for so many years in part because the growing "AV professional wannabe" crowd who just used the system mostly for general (rather than low latency sensitive) applications didn't really notice or care about the hit to throughput or security vulnerability. Noticeable in benchmarks, but not in real life. My first point in saying this is that benchmarks don't necessarily tell us what will give the greatest benefit to the greatest number of users with minimal or no reconfiguration. Eg, who cares if it takes even 10% more milliseconds to transcode an AV file or compile code (on same hardware configred differently) if it means you could also run latency sensitive apps at a consistent (low jitter) amd low latency without having to reconfigure anything and maintaining a generally responsive system? People often just walk away from that anyway (either physically, eg smoke or coffee break, or figuratively, eg task switching, in which case a responsive system would be a higher priority than crunching the numbers slightly faster). My second point is I think obsession over benchmarking risks losing the forest through the trees and really often doesn't account for anything close to real world performance optimizations. But even then it could be argued this is only because we fail to consider important parameters in common performance benchmarks, such as "responsiveness" and "jitter" and "latency" alongside obsessing over throughput and to a lesser extent power management. For me, the core of this question means finally coming to clarity about what "optimal balance" means for the widest variety of desktop and server applications, just as Apple did accidentally a few decades ago with its client systems I think this requires considering a variety of factors instead of an unrealistically narrow idea of "performance" that does not factor in real world user experience. Eg the idea that most users often will appreciate improvements in latency and responsiveness without really much noticing the cost of throughput until someone starts obsessing over throughput benchmarks with relatively minute differences as far as our intuitive or subconscious experience is concerned. Less user frustration from fewer to no buffer overruns or perceived interface hiccups again draw on concepts such as "reliability" and "default breadth of utility" FWIW I think a lot of throughput obsession is about internalized and institutionalized planned obsolescence. It's the primary benchmark of OEM system performance, and a fairly lazy way to measure performance at that. 4min 30sec for a transcoded file would be considered hugely different than 5min 30sec on the same hardware, but for the average user who would just take a smoco break or switch tasks it doesn't matter as long as the system remains responsive and functional. And you'll never get to the transcoding in the first place if the system keeps recording buffer xruns that ruin a file being processed or recorded in real time due to system latency that is too high or variable for the sort of performance and responsiveness needed. Another way to put this is there's the social-economic dimension of performance vs the psychological dimension of performance. While the psychological one is arguably more important and humane it is often at odds with the social-economic dimension which seeks to sell more new systems because they are "faster" (and only very marginally and narrowly defined). I cpuld easily be out of the loop bur I just don't see this stuff considered often enough in discussions of performance optimization. Ethan On Sat, Jan 6, 2024, 20:20 Steve Langasek