将中断亲和性和 io 处理线程亲和性设置到同一个核心是一种好习惯吗？答案

【问题标题】：Is it a good practice to set interrupt affinity and io handling thread affinity to the same core?将中断亲和性和 io 处理线程亲和性设置到同一个核心是一种好习惯吗？
【发布时间】：2018-02-07 09:05:24
【问题描述】：

我正在尝试了解 irq 亲和性及其对系统性能的影响。

我查看了why-interrupt-affinity-with-multiple-cores-is-not-such-a-good-thing，了解到应该将 NIC irq affinity 设置为与处理网络数据的核心不同的核心，因为处理不会被传入的 irq 中断。

我对此表示怀疑，因为如果我们使用不同的内核来处理来自 irq 内核的数据，在尝试从内核检索网络数据时，我们将获得更多的缓存未命中。所以我实际上相信，通过将 irq 亲和性设置为处理传入数据的线程的同一个核心，会由于缓存未命中率降低而提高性能。

我正在尝试提供一些验证码，但在我展示任何结果之前，我是否遗漏了什么？

【问题讨论】：

标签： performance networking linux-kernel interrupt

【解决方案1】：

IRQ 亲和力是一把双刃剑。根据我的经验，它可以提高性能，但只能在具有预定义工作负载的非常特定的配置中。就您的问题而言，（仅考虑 RX 路径）通常当 NIC 卡中断其中一个核心时，在大多数情况下，中断处理程序不会做很多事情，除了触发一种机制（下半部分，tasklet，内核线程或网络堆栈线程）在其他上下文中处理传入的数据包。如果同一个数据包处理核心正在处理中断（ISR 处理程序没有做太多），它必然会由于上下文切换而失去一些缓存优势，并且可能会增加缓存未命中。影响有多大，取决于各种其他因素。

在 NIC 驱动程序中，核心的关联性通常与每个 RX 队列对齐[将每个 RX 队列处理跨不同的核心分开]，这提供了更多的性能优势。

【讨论】：

默认的affinity是以RR的方式将IRQ分发到所有的核心？根据您的描述，从 IRQ 亲和性中排除处理核心是一种获得性能优势的有希望的方法。
理论上是的，但实际上可能并不重要。还有其他方法可以获得更好的性能，例如合并中断或轮询

【解决方案2】：

控制中断亲和性可能很少有有用的应用。很少有人想到这个冲刺。

隔离内核 - 防止 I/O 负载扩散到关键任务 CPU 内核或 RT 优先级专用的内核（计划的软中断可能会在这些内核上饿死）
通过在多 CPU 系统的相关 NUMA 上保持中断来提高系统性能 - 吞吐量和延迟
CPU 效率 - 例如专用 CPU、NIC 通道及其对单个应用程序的中断将从该 CPU 中挤出更多，在流量大的用例中多出约 30%。这可能需要流量控制以使传入流量以通道为目标。注意：没有亲和力的应用程序似乎可以提供更多的吞吐量，但会将负载溢出到许多核心上）。收益归功于缓存局部性和上下文切换预防。
延迟 - 如上所述设置应用程序将使延迟减半（在现代系统上从 8us 到 4us）

【讨论】：