2019独角兽企业重金招聘Python工程师标准>>> 
本文是一篇译文，原文的地址为：http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-linux
Introduction
硬件中断是非常昂贵的，因为它会消耗大量的CPU处理能力。硬件和软件工程师已经做了很多工作试图改变这种状况，但硬件中断仍然会消耗大量CPU。
硬件中断对桌面系统的影响并不明显，具体信息可以通过/proc/interrupts文件来查看。这个文件中记录了所有的硬件设备以及它们在每个CPU上收到的中断数目。如果是在一个常规的桌面系统上，将会看到系统中处理的中断数目是相对较小的。即使是每秒处理百万数据包的超强服务器，一秒内也只需处理数万个中断。即便如此，通过恰当的方式降低中断所带来的CPU开销仍将毫无疑问的帮助提升系统性能。
But really, what can we do about interrupts?
事实上，还有很多事情可以做。许多Linux的发行版中都包含了能够明显改善这种情况的修改。一种有效的技术就是NAPI，它显著的降低了中断的数目和开销，因此现代服务器无需再忍受1Gbps的以太网链路。NAPI现在已经成为了内核的一部分。其他的技术还有像中断合并等。
在本文中，我将把注意力放在一个最有力的中断处理优化技术上。
SMP affinity
术语“SMP亲和性” 或 “处理器亲和性”有着广泛的含义，需要首先来解释一下。“亲和性”是指在多处理器系统中，将特定的任务放到特定的处理器上执行。例如，当进程Y运行在处理器X上时，它们之间就具有了亲缘关系，处理器会将进程的部分内存内容缓存在cache中，因此频繁的将进程调度到不同的处理器上是一种低效的方法。
考虑到中断的情况，“SMP 亲和性”是指特定的中断由哪个处理器来处理。与进程的情况不同，将中断绑定到特定的CPU上将会引起性能下降。下面就来说说为什么会这样。中断处理程序通常都非常小，因此它所占用的内存也很小，也就是说将中断保持在同一个CPU上不会改善缓存命中的情况。相反，过多的中断会使一个核心过载，而其他的核心却处在相对空闲的状态。调度程序却对此一无所知，它会假设我们的中断处理核心与其他核心一样繁忙，由此带来的结果就是你可能会面临一个瓶颈，这是由于某些进程或线程运行在了只有90%可用处理能力的核心上所造成的。
事情还可能会变得更加糟糕，因为在默认情况下core0会被用来处理所有中断。在一个繁忙的系统上，所有的中断加起来可能会消耗掉core0 30%的处理能力。假设所有核心都具有相同的处理能力，我们会发现我们的软件系统只能有效地利用CPU全部处理能力的70%。
Who's responsible
APIC or Advanced Programmable Interrupt Controller 已经集成到所有现代x86体系架构的系统中 --- 包括 SP（single-processor）和MP。APIC负责递交中断，并决定中断的去向（到哪个核心）。
默认情况下，APIC将所有中断递交到core0，这就是为什么在主流现代Linux操作系统上/proc/interrupts文件的输出内容看起来如下的原因：
CPU0 CPU1 CPU2 CPU30: 123357 0 0 0 IO-APIC-edge timer8: 0 0 0 0 IO-APIC-edge rtc11: 0 0 0 0 IO-APIC-level acpi
169: 0 0 0 0 IO-APIC-level uhci_hcd:usb1
177: 0 0 0 0 IO-APIC-level qla2xxx
185: 0 0 0 0 IO-APIC-level qla2xxx
193: 12252 0 0 0 IO-APIC-level ioc0
209: 0 0 0 0 IO-APIC-level uhci_hcd:usb2
217: 468 0 0 0 IO-APIC-level eth0
225: 285 0 0 0 IO-APIC-level eth1
NMI: 120 66 76 45
LOC: 123239 123220 123187 123065
ERR: 0
MIS: 0看到了吗，CPU0处理了所有的硬件中断，这就是你将在一个错误配置了中断SMP亲和性的系统上看到的情形。
Simple solution for the problem
随着APIC的引入，这个问题已经有了多种解决方案。APIC包含了若干中断传递和指定模式，包括物理模式和逻辑模式，固定模式和低优先级模式，等等。一个重要的事实是它有能力将中断递送到任何一个核上，甚至在它们之间进行负载均衡。
APIC也有配置限制，它只能配置在前8个核心上。如果你有多于8个的核心，不要指望序号大于7的核心能够收到中断。
默认情况下，它的操作是physical/fixed的。也就是说，它会将特定的中断传递到特定的核心上（默认是core0），但你也可以方便的更改接收指定中断的核心号。
对于/proc/interrupts文件第一列中的每个IRQ号，在/proc/irq/目录下都有一个对应的子目录，其中包含了一个名为smp_affinity的文件，它可以用来修改处理这个中断的核心号。读这个文件可以获得一个由十六进制表示的掩码，其中的每一位代表一个核心。当特定位置位时，APIC会将这个中断传递到对应的核心。
让我们来看一个例子：
#
# cat /proc/interruptsCPU0 CPU1 CPU2 CPU30: 19599546 0 0 0 IO-APIC-edge timer8: 0 0 0 0 IO-APIC-edge rtc11: 0 0 0 0 IO-APIC-level acpi
169: 0 0 0 0 IO-APIC-level uhci_hcd:usb1
177: 0 0 0 0 IO-APIC-level qla2xxx
185: 0 0 0 0 IO-APIC-level qla2xxx
193: 95337 0 0 0 IO-APIC-level ioc0
209: 0 0 0 0 IO-APIC-level uhci_hcd:usb2
217: 100778 0 0 0 IO-APIC-level eth0
225: 56651 0 0 0 IO-APIC-level eth1
NMI: 466 393 422 372
LOC: 19600453 19600434 19600401 19600279
ERR: 0
MIS: 0
#
#
# echo "2" > /proc/irq/217/smp_affinity
# cat /proc/interruptsCPU0 CPU1 CPU2 CPU30: 19606722 0 0 0 IO-APIC-edge timer8: 0 0 0 0 IO-APIC-edge rtc11: 0 0 0 0 IO-APIC-level acpi
169: 0 0 0 0 IO-APIC-level uhci_hcd:usb1
177: 0 0 0 0 IO-APIC-level qla2xxx
185: 0 0 0 0 IO-APIC-level qla2xxx
193: 95349 0 0 0 IO-APIC-level ioc0
209: 0 0 0 0 IO-APIC-level uhci_hcd:usb2
217: 101027 49 0 0 IO-APIC-level eth0
225: 56655 0 0 0 IO-APIC-level eth1
NMI: 466 393 422 372
LOC: 19607629 19607610 19607577 19607455
ERR: 0
MIS: 0
#可以看到，当我们输入了这个神奇的命令后，CPU1将代替CPU0，开始从eth0接收中断。用于完成这件事情的echo命令非常有趣，如果我们将“4”写入这个文件中，那么CPU2将代替CPU1来处理eth0的中断，就像之前已经提到的，它采用了位掩码的方式，每一位与一个单独的CPU关联。
那么写入“3”又会怎么样呢？理论上，这时APIC应该将中断传递到CPU0和CPU1上，不幸的是，这里的情况会更复杂一些。具体的行为依赖于APIC是否工作在 physical "destination mode" 以及 low priority "delivery mode"模式下。如果是的话，那么你不太可能看到CPU0处理所有中断，这是因为当APIC工作在 physical / low priority模式下的时候，会自动在前8个核心之间进行负载均衡。
因此，如果在你的系统上CPU0默认处理了全部的中断，这可能暗示了APIC的配置问题。
Ultimate solution
首先，不幸的是，别无选择，除非替换内核。配置APIC是内核的工作，如果我们想改变现状就只能在内核里修改它，那么唯一的问题就是，用什么来替换内核？
我在OpenSuSE 10.2（内核版本2.6.18）上进行了测试，使用OpenSuSE的默认内核配置（/proc/config.gz）安装2.6.24.3版本的内核（当时最新的版本）来修正这个问题。在这个内核上，事情看起来正确了：
# cat /proc/interruptsCPU0 CPU1 CPU2 CPU30: 728895 728796 728624 728895 IO-APIC-edge timer8: 0 0 0 0 IO-APIC-edge rtc11: 0 0 0 0 IO-APIC-fasteoi acpi16: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb119: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb224: 14090 14090 14327 14056 IO-APIC-fasteoi ioc049: 7 9 7 8 IO-APIC-fasteoi qla2xxx50: 8 12 11 10 IO-APIC-fasteoi qla2xxx77: 2849 2759 2841 2827 IO-APIC-fasteoi eth078: 25072 25138 24996 24980 IO-APIC-fasteoi eth1
NMI: 0 0 0 0
LOC: 2915270 2915256 2915228 2915092
ERR: 0看起来不错不是吗？所有的核心都在处理中断，工作效率也因此得到了最大化。
还有一个内核的配置选项横在我们的道路上，一旦移除掉它就能够在所有晚于2.6.10版本的内核上获得类似的效果。这个选项就是CONFIG_HOTPLUG_CPU，它增加了对CPU热插拔的支持。关掉这个选项，并正确的配置APIC。
实际上这很好理解，APIC被告知使用哪个CPU来接收中断，你需要增加一段代码来告知APIC如何处理CPU的移除事件 --- 而CPU的移除事件正是CONFIG_HOTPLUG_CPU允许你做的事，我假定这个功能在较早时被内核遗忘了，并在2.6.24.3版本之后被添加了进来。
Conclusion
我们已经看到，通过修改内核的配置可以获得实实在在的改进。在一个繁忙的系统中，通过一个小小的改动就可以成倍的提升服务器的生产力。
希望你能够认同这篇文章的内容，并将这些技术用到实际中去。
