Today I've read this opinion however I don't understand the topic of interrupts at all, so it would be nice if knowledgeable people chimed in and explained the rationale behind using this daemon in the past and whether it's advisable or not to use it nowadays.
Asked
Active
Viewed 846 times
2 Answers
0
My opinion is that it is not that much a question of past / present, modern vs ancient system. That it is more a question of the knowledge you get of your system, of your workload and of what you want to optimize (latency vs throughput) The more you know, the less you want whatever kind of helper to put its dirty undeterministic hands on your system and decide instead of you. (*1)
At boot time, interrupts are generally shared evenly (in numbers) between CPUs. (That is to say irrespective of their possible frequency of occurrence at runtime, irrespective of the cpu time needed by the handlers to complete). Depending on the dispatch, depending on the workload, this can induce undesirable latencies.
Let's say for example that I get 2 PCI sound cards, both used in parallel by ardour at 96KHz sampling rate with very limited buffers (in order to reduce latency) adding to that some usb-midi hardware. (*2)
In this sort of case, I already did my best avoiding irq sharing (different devices using same IRQ) , I then certainly do not want the 3 associated irqs (one per device) to stand on the same CPU. And, if possible, not on the CPU used by Ardour… and this simply because :
- Since both are of equivalent importance, the irq threads will run under the same real time priority and therefore, the processing of any interrupt occurring while processing another IRQ will be delayed, this increasing latency if not even worse : XRUNS (samples being dropped because of buffer overruns).
- The code and data structures needed to process any one of these interrupts will have the lowest possible likelihood to be in the processor data and instruction cache, this inducing additional latency each time an interrupt is processed.
The irqbalance daemon could perhaps, after some time, at some instant, discover that the initial configuration is suboptimal and decide (at run time) to (costly) reorganize IRQ pinnings (with possible U-turns when I stop using the midi keyboard ?) Hmmm... Possibly !
But being aware of all that, I will myself, once and for all, isolate one cpu for each one of these 3 IRQs and have the fourth one dealing with everything else. (Of course I can't go further… I run a core II ;-) and… irqbalance daemon : HandsOFF, I know what I'm doing !
At the opposite but leading to identical decision regarding the irqbalance daemon, if I know that I only care about the throughput of my cpu-bound tasks, I should pin all irqs to one housekeeping cpu and have all the other cpu sharing my workload undisturbed.
Then comes the inexperienced so called "common desktop user" who wants its system capable of doing everything and more in what it believes the very best run time conditions without having to bother with low level software considerations. (No disrespect meant, I happen to be sometimes (but rarely) one of these)
In this case, running the irqbalance daemon might sometimes (and costly) help achieving lower latencies but in a definitely undeterministic way.
Anyway, watching a 48Kz / 60 fps video while answering some mail under an 8 cores system, who would notice ? This might incidentally be the reason why you could link the interest of the irqbalance daemon with modernity : The more modern, the more cpus, higher their frequencies, the less need to worry about cpu pinning.
Disclaimer : (*3)
Going now deeper technically in the management of IRQs :
Under Linux, there are two ways to handle interrupts (to achieve the job needed when an IRQ (or MSI) occurs :
The old traditional way : Achieve all the job into kernel space as part of the IRQ handler. This will achieve the highest possible throughput but will have the inconvenience to interrupt the running task (that could be of a far higher importance) and mask other possibly more important IRQs for all the time of processing.
On real time systems, you of course do not want that.The threaded IRQ way : Achieve the very minimum of the job as part of the IRQ handler. The part that must be achieved all interrupts masked and leave most part of the job to be achieved by a kernel thread scheduled SCHED_RR when its priority will have become the highest.
This will of course increase the processing time since this will require at least 2 additional context switches but this is of course the preferred way for real time systems in which relative priorities (between tasks and between IRQ handlers and between tasks and IRQ handlers) do matter.
In this threaded IRQs context, the irq thread will default to be pinned on the CPU handling the IRQ. BUT, at run time, depending on load considerations, the scheduler might decide to reschedule that kernel thread on some other CPU (if any iddling). (*4)
Therefore, since early 2020, in a threaded irq context, having some daemon re-fiddling IRQ's handler pinning (live, at great costs) is definitely (and objectively) counter-productive. Let the scheduler decide what is best considering the sharing of instant workload!
*1 : Think of your GPS : Turn right ! strait on ! Hmmm U turn !
*2 : Typical live performing DAW (mine at least :-P)
*3 : This answer could be understood opinion based. I would'nt be honest hiding that I hate undeterministic systems configuring my system at runtime in my back. I hate these even more if they pretend their fiddlings matching my will.
*4 : Which is possible since early 2020 thanks to John Garry's patch.
MC68020
- 6,281
- 2
- 13
- 44
-1
irqbalance periodically checks /proc/interrupts to see which CPU/core handles which interrupts and tries to spread interrupt handling evenly around using the interface in /proc/irq. This helps keep latencies down and also improves performance in case of CPU bound bottlenecks in interrupt handling.
Interrups are signalled to the CPU by devices like storage and network devices or hardware timers. For example, when a packet arrives your NIC (network interface controller) might fire an interrupt to let the CPU know about it so it can process it. Almost all hardware will communicate with the CPU in this way.
Sadly, some interrupts are impossible to move around, so if one of those is causing high CPU load nothing can be done. Another limitation is that not all kernel drivers enable offloading interrupt handlers to other CPUs/cores even if they support it. To work around this you can try adding the threadirqs kernel parameter at boot.
John Smith
- 2,659
- 1
- 13
- 19
