irqbalance 守护进程是否应该在现代桌面 x86 系统上使用？

Question 1

我的观点问题在于，这并不是过去/现在、现代与古代制度的问题。这更多的是一个问题您对系统、工作负载以及想要优化的内容的了解（延迟与吞吐量）您知道的越多，您就越不希望任何类型的助手将其弄脏不确定的掌握您的系统并代替您做出决定。 (*1)

在启动时，中断通常在 CPU 之间均匀（按数量）共享。（也就是说，无论它们在运行时可能发生的频率如何，无论处理程序完成所需的 CPU 时间如何）。根据调度和工作负载，这可能会导致不期望的延迟。

举例来说，我有 2 个 PCI 声卡，两者都由 ardor 以 96KHz 采样率并行使用，缓冲区非常有限（为了减少延迟），并添加了一些 USB-MIDI 硬件。 (*2)
在这种情况下，我已经尽力避免 irq 共享（不同的设备使用相同的 IRQ），那么我当然不希望 3 个关联的 irq（每个设备一个）位于同一个 CPU 上。并且，如果可能的话，不要在 Ardour 使用的 CPU 上......这仅仅是因为：

由于两者具有同等重要性，IRQ 线程将在相同的实时优先级下运行，因此，处理另一个 IRQ 时发生的任何中断的处理都会被延迟，这会增加延迟（如果不是更糟的话）：XRUNS（样本被丢弃，因为缓冲区溢出）。
处理这些中断中的任何一个所需的代码和数据结构在处理器数据和指令高速缓存中的可能性最低，这会在每次处理中断时产生额外的延迟。

irqbalance 守护进程可以也许一段时间后，在某个时刻，发现初始配置不是最优的，并决定（在运行时）（代价高昂）重新组织 IRQ 引脚（当我停止使用 midi 键盘时可能会掉头？）嗯...可能！
但考虑到这一切，我自己将一劳永逸地为这 3 个 IRQ 中的每一个隔离一个 cpu，并让第四个 IRQ 处理其他所有事情。（当然我不能更进一步……我运行 core II ；-）并且……irqbalance 守护进程：HandsOFF，我知道我在做什么！

相反，但会导致关于 irqbalance 守护进程的相同决定，如果我知道我只关心 cpu 绑定任务的吞吐量，我应该将所有 irqs 固定到一个家政cpu 并让所有其他 cpu 不受干扰地分担我的工作负载。

然后是缺乏经验的所谓“普通桌面用户”，他们希望其系统能够完成所有任务，甚至更多。相信最好的运行时条件，而不必担心低级软件的考虑。（没有不尊重的意思，我有时（但很少）碰巧是其中之一）
在这种情况下，运行 irqbalance 守护进程可能会有时（并且成本高昂）有助于实现更低的延迟，但绝对是不确定的方式。

无论如何，在 8 核系统下一边看 48Kz/60 fps 视频一边回复邮件，谁会注意到呢？顺便说一句，这可能就是您可以将 irqbalance 守护进程的兴趣与现代性联系起来的原因：越现代，CPU 越多，频率越高，就越不需要担心 cpu pinning。

免责声明：(*3)

现在从技术上更深入地探讨 IRQ 的管理：

在Linux下，有两种方法来处理中断（以实现IRQ（或MSI）发生时所需的工作：

老传统方式：将所有工作实现到内核空间作为IRQ处理程序的一部分。这将实现尽可能高的吞吐量，但会不便中断正在运行的任务（这可能非常重要）并在整个处理过程中屏蔽其他可能更重要的 IRQ。
在实时系统上，您当然不希望这样。
线程式IRQ方式：作为 IRQ 处理程序的一部分，完成最低限度的工作。必须实现的部分将所有中断屏蔽，并将大部分作业留给由调度 SCHED_RR 的内核线程来实现（当其优先级变为最高时）。
这当然会增加处理时间，因为这将需要至少 2 个额外的上下文切换，但这当然是实时系统的首选方式，其中相对优先级（任务之间、IRQ 处理程序之间以及任务和 IRQ 处理程序之间）确实很重要。

在此线程 IRQ 上下文中，irq 线程将默认固定在处理 IRQ 的 CPU 上。但是，在运行时，根据负载考虑，调度程序可能决定在其他 CPU 上重新调度该内核线程（如果有空闲）。 (*4)
因此，从 2020 年初开始，在线程化的 irq 上下文中，让一些守护进程重新调整 IRQ 的处理程序固定（实时，代价高昂）肯定（客观上）会适得其反。让调度程序决定什么是考虑即时工作负载共享的最佳方案！

*1：想想你的 GPS：右转！海峡上！嗯，掉头！

*2：典型的现场表演 DAW（至少是我的 :-P）

*3：这个答案可以根据意见来理解。我不会诚实地隐藏我讨厌在运行时配置我的系统的不确定系统。如果他们假装自己的摆弄符合我的意愿，我就更讨厌他们了。

*4：自 2020 年初以来，这成为可能，这要归功于约翰·加里的补丁。

Answer