简介：在 ARM64 平台上使用 perf 做性能剖析时，火焰图经常把 local_irq_enable() 显示为热点，这并非真实瓶颈，而是中断屏蔽区间造成的采样盲区。本文从 ARM64 中断架构与 PMU 采样机制出发，解释这一现象的成因、x86 的对照方案，以及 ARM64 社区多年补全不可屏蔽中断能力的演进路径，帮助开发者读懂被误导的性能数据，规避剖析陷阱。
在 ARM64 服务器上做性能分析时，很多开发者都遇到过一种让人困惑的现象：火焰图显示大量 CPU 时间消耗在 local_irq_enable() 这个函数上。按照直觉，这个函数只是重新开启本地 CPU 中断，不应该成为真正的性能瓶颈。但如果火焰图反复指向它，开发者很容易误判为内核在中断使能路径上存在性能问题。
更常见的后续操作是：继续深入分析、尝试优化、调整内核参数，结果收效甚微。因为真正的问题不在这个函数本身，而在于它恰好成为了采样中断的“泄洪口”。
业内技术博客和内核开发者曾经反复解释过这一现象：这不是 perf 工具的缺陷，也不是内核实现异常，而是 ARM64 平台上性能采样机制与中断屏蔽机制叠加之后产生的系统性偏差。理解这一偏差，需要从性能监控单元（PMU）的中断投递方式说起。
perf 采样型剖析的基本原理是：PMU 在 CPU 上按一定频率触发性能计数器溢出中断，内核在中断处理函数中记录当前正在执行的指令地址或调用栈。经过足够多次采样后，统计这些地址出现的频率，就可以近似推导出 CPU 时间主要消耗在哪些代码路径上。
这个过程隐含了一个前提：PMU 溢出中断必须能够在任意代码位置打断 CPU。如果某段代码在执行期间关闭了中断，PMU 溢出中断就无法及时送达。ARM64 上的普通中断会受到 PSTATE 寄存器中中断屏蔽位的影响。内核进入临界区时会调用 local_irq_disable() 关闭本地中断，离开临界区时再调用 local_irq_enable() 恢复。
这样就会产生一种典型的采样偏移：
local_irq_enable() 恢复中断时，挂起的 PMU 中断几乎在同一时刻被释放；local_irq_enable() 内部或其附近；local_irq_enable() 的采样计数被异常放大。换句话说，火焰图上看到的“热点”并不是真正消耗 CPU 的位置，而是中断被重新打开的位置。真正消耗 CPU 的代码可能藏在某段较长的中断屏蔽区间里，但它们在火焰图上几乎是不可见的，形成了一片采样黑洞。
对比 x86 平台可以更清晰地理解这个问题。x86 架构提供了一种不可屏蔽中断（Non-Maskable Interrupt，NMI），这种中断不受普通中断屏蔽位的影响。即使 CPU 当前关闭了普通中断，NMI 仍然可以打断执行流。
在 x86 上，perf 可以将 PMU 溢出中断配置为 NMI 模式。这样，即便内核正处于 local_irq_disable() 保护的临界区中，PMU 溢出依然能够送达，采样逻辑仍然可以记录到临界区内部的指令地址。因此，x86 上火焰图不会因为中断屏蔽而出现系统性的采样空洞，local_irq_enable() 也不会被误判为热点。
这一差异本质上反映了两套体系结构对中断模型的不同取舍。x86 在早期就为调试和性能监控场景预留了独立于普通中断屏蔽机制的 NMI 通道，而 ARM64 的 A-profile 架构则长期没有原生等价能力。
ARM64 的中断控制器 GIC（Generic Interrupt Controller）采用的是一套统一的优先级模型。中断的分组、抢占、屏蔽、响应都通过优先级机制来协同完成。这种设计在嵌入式和移动场景下具有明显优势：模型统一、行为可预测、软件实现相对简洁。
但统一优先级模型也有代价。当一个中断被配置为较低优先级时，它就可能被更高优先级的处理流程屏蔽；当 CPU 进入临界区关闭中断时，所有通过普通路径投递的中断都会被延迟。对于性能剖析所需的“必须打断”语义，这种模型并不能天然满足。
在服务器场景下，这一限制变得更加突出。服务器负载复杂、中断频繁，内核中大量使用自旋锁、RCU 临界区、关中断保护等机制。一旦这些临界区执行时间较长，PMU 采样就会出现明显盲区。开发者在分析性能问题时，看到的火焰图可能系统性偏离真实热点分布。
ARM64 没有原生 NMI，这是 A-profile 架构一个被长期讨论的限制。它不是某个内核版本的缺陷，而是体系结构层面的设计选择。要弥补这一能力，需要从架构规范、中断控制器行为、内核中断子系统等多个层面协同演进。
从社区意识到这个问题的严重性，到 ARM64 具备相对可用的伪不可屏蔽中断能力，经历了相当长的时间。整个过程大致可以分为三个阶段。
第一阶段，社区主要尝试在软件层面规避。早期做法包括调整 perf 采样策略、避免在关键路径上长时间屏蔽中断、或者通过辅助机制减少采样盲区。但这些手段都只能减轻症状，无法从根本上解决问题。因为只要 PMU 中断走的是普通中断路径，它在中断屏蔽区间内就天然会被延迟。
第二阶段，开始探索利用 GIC 的优先级机制模拟不可屏蔽行为。基本思路是：将 PMU 中断配置为比普通中断更高的优先级，同时在内核中区分“普通关中断”和“完全不可屏蔽”两种状态。这样，当 CPU 关闭普通中断时，高优先级的 PMU 中断仍然可以被投递。这一方案被称为伪不可屏蔽中断（pseudo-NMI）。
这一阶段的难点在于，内核中大量代码路径假定“关中断之后不会再被普通中断打断”。一旦引入伪 NMI，就必须审计所有可能在 NMI 上下文中执行的内核代码，确保其中的锁操作、内存分配、数据结构访问都是 NMI 安全的。例如，在 NMI 上下文中不能使用普通自旋锁，不能调用可能睡眠的函数，也不能随意访问未做 NMI 安全保护的 per-CPU 数据。
第三阶段，随着架构规范和内核实现的逐步完善，ARM64 的 pseudo-NMI 能力进入可用状态。内核需要确认硬件是否支持通过 GIC 将特定中断提升到足够高的优先级，并在启动阶段进行探测。如果硬件实现存在问题，启用 pseudo-NMI 可能导致系统不稳定甚至死机。这正是内核维护者所感叹的：外部有太多坏掉的硬件，在启用 pseudo-NMI 时会痛苦地死机。
当 ARM64 平台成功启用 pseudo-NMI 后，perf 的采样行为会发生变化。PMU 溢出中断不再受普通中断屏蔽位约束，能够在临界区内送达。火焰图不再把 local_irq_enable() 当作虚假热点，采样数据更接近真实 CPU 时间分布。
但启用伪 NMI 也带来了新的内核设计要求。所有可能被 NMI 打断的代码路径都必须经过审查。例如：
因此，pseudo-NMI 并不是一个可以无条件开启的开关，而是一项需要硬件、内核、驱动和性能工具共同配合才能稳定使用的能力。
对在 ARM64 平台上做性能剖析的工程师来说，理解这一机制有非常实际的指导意义。
首先，看到火焰图中 local_irq_enable() 异常偏高时，不应立即怀疑该函数本身存在性能问题。更有价值的做法是，检查是否存在长时间的中断屏蔽区间，并尝试通过其他观测手段确认这些区间内是否存在真正的热点。
其次，如果条件允许，可以确认当前硬件和内核是否支持 pseudo-NMI，并评估开启后的稳定性。开启后重新采集 perf 数据，对比火焰图变化，通常能发现此前被隐藏的热点。
再次，对于无法启用 pseudo-NMI 的环境，可以采用代码插桩、定时采样、内核追踪点等手段辅助分析。虽然这些方法不如硬件 PMU 采样方便，但在中断屏蔽区间内仍然可能提供有价值的线索。
最后，在云环境中使用 ARM64 实例时，需要注意虚拟化层对 PMU 虚拟化和中断投递的影响。不同的虚拟化实现可能对 pseudo-NMI 能力有不同的暴露程度，性能剖析结果也可能受到宿主机调度和中断虚拟化策略的干扰。
ARM64 性能火焰图中的 local_irq_enable() 热点，本质上是一个由中断屏蔽与 PMU 采样机制叠加形成的观测假象。它揭示了一个更深层的事实：性能剖析工具的准确性，依赖于硬件平台是否具备在任意执行上下文中打断 CPU 的能力。
x86 凭借原生 NMI 天然规避了这一类问题，而 ARM64 则经历了从无到有、从软件规避到架构补全的长期演进。理解这一过程，不仅能帮助开发者更准确地阅读性能数据，也提醒我们在跨架构进行性能对比时，必须考虑底层中断模型差异对观测结果的影响。
对于严肃的性能工程而言，火焰图从来不是一个可以直接照单全收的“真相图”，它是一套观测系统的输出。只有理解了观测系统本身的工作机制和局限，才能从扭曲的数据中还原出真正的性能图景。