为什么越来越多云计算厂商推出 ARM 架构产品？

一、从一张”骗人”的火焰图说起

在ARM64服务器上做过性能分析的同学，很可能见过这样一个奇怪的现象：火焰图顶部最显眼的”热点”不是业务逻辑，也不是锁竞争，而是 local_irq_enable() 这类中断使能函数。看起来CPU把大量时间花在了”重新打开中断”这件琐事上，但把这段代码翻来覆去地看，也找不出任何耗时操作。

这不是perf的bug，也不是内核的bug，而是采样机制在特定硬件条件下给出的失真结果。业界文档中对此有明确描述：用户经常抱怨大量CPU时间似乎花在了 local_irq_enable() 上，但这并非真正的瓶颈——性能监控单元（PMU）的中断只是在IRQ重新使能的那一刻才被送达，于是采样器”总是”在这个函数处命中。

换句话说，火焰图展示的不是”CPU在哪里花了时间”，而是”采样中断在哪里被允许送达”。当真正的时间消耗发生在中断被屏蔽的区间内，采样器根本进不去，那段区间在图上表现为一片空白，而中断恢复点反而被反复采样、放大成一个虚假的热点。基于这张图去做优化，方向从一开始就是错的。

二、问题的根源：中断屏蔽与采样可达性

要理解这个现象，需要回到内核的临界区语义。内核在执行 local_irq_disable() 之后进入临界区，普通中断被屏蔽，其中就包括perf采样所依赖的PMU中断。如果一段热点代码恰好位于较长的中断屏蔽区间内——例如调度器核心路径、锁的慢路径、某些驱动的高频操作——采样中断无法打断CPU，profiler自然拿不到这段区间的样本。

与之相对，另一类处理器架构从设计之初就提供了不可屏蔽中断（NMI，Non-Maskable Interrupt）。perf的采样中断可以配置为NMI，即使CPU处于中断屏蔽状态，NMI依然能够打断执行流、抓取现场。因此在那类架构上，火焰图不会出现”中断屏蔽黑洞”，采样点分布更接近真实的时间分布。

ARM64的处境则不同。准确地说，ARM64 A-profile架构长期没有原生的NMI。其通用中断控制器（GIC）的中断管理哲学是”通过优先级实现一切”：分组、抢占、屏蔽统一建模在优先级机制之下。这套统一模型在嵌入式和移动场景中工作良好——外设中断有明确的优先级层次，屏蔽就是”把优先级门槛调高”。但当服务器场景需要一种”绝对不可屏蔽”的中断来支撑性能分析与故障诊断时，纯优先级屏蔽模型的局限性就暴露出来了：任何基于优先级的屏蔽，理论上都可以把某个优先级以下的中断全部挡在门外，采样中断也不例外。

三、三代方案：一条走了多年的补课之路

填补这一能力缺口并非易事，社区经历了多轮方案迭代与邮件列表上的反复争论，大致可以归纳为三个阶段。

第一代：伪NMI的早期尝试。 核心思路是在GIC之上模拟出”近似不可屏蔽”的效果，通过在特定硬件条件下绕过常规屏蔽路径来投递高优先级中断。这一代方案的局限在于对硬件行为依赖过强，在不同实现上表现不一致，稳定性难以保证。业界曾有过非常直白的总结：外面有太多”坏掉”的硬件，一旦启用伪NMI就会痛苦地死机。这句话道出了问题的本质——软件方案能否成立，取决于底层硬件是否严格遵守规范。

第二代：面向服务器平台的规范化支持。 随着ARM服务器平台逐渐成熟，GICv3/v4的优先级机制被更精细地利用，伪NMI的投递路径被重新设计，尽量在标准中断模型内实现”屏蔽状态下仍可送达”的语义。这一阶段的关键工作是把”能用”变成”可靠”，处理各种边界条件：嵌套中断、优先级反转、与调试异常的交互等。

第三代：与内核NMI框架的融合。 最终目标不是造一个ARM64专属的旁路机制，而是让伪NMI真正融入内核通用的NMI基础设施，使perf、看门狗、崩溃转储等依赖NMI的子系统在ARM64上获得与其它架构一致的行为。至此，ARM64才算”学会了”别的架构生来就会的事——而这个过程，前后跨越了相当长的时间。

四、对性能分析的现实影响

在伪NMI能力尚未普遍可用的平台上，开发者需要意识到采样失真的几种典型表现，并采取应对手段。

识别失真信号。 如果火焰图中出现以下特征，应怀疑采样盲区：热点集中在 local_irq_enable() / local_irq_restore() 等中断恢复点；热点分布与代码审查结论严重不符；调整采样频率后热点位置发生漂移而非收敛。

交叉验证。 不要只依赖单一采样源。可以结合硬件计数器的事件计数（而非采样中断）、内核tracepoint、以及基于时间戳的埋点统计来交叉印证。例如用计数模式统计某段临界区的进入次数与停留时长：

/* 伪代码：用计数与时间戳辅助定位临界区耗时 */
u64 start = local_clock();
local_irq_disable();
/* ... 临界区 ... */
local_irq_enable();
u64 delta = local_clock() - start;
if (delta > threshold)
    trace_critical_section(delta);

缩小临界区。 无论采样是否准确，缩短中断屏蔽区间本身就是正确的工程实践。把不必要的操作移出临界区、用细粒度锁替代大范围屏蔽、把批量处理拆分为可中断的分段，都能同时改善延迟表现与可观测性。

关注平台能力差异。 在选型或部署时，应确认目标平台的内核版本与固件是否支持伪NMI路径。同一份应用在不同ARM64平台上可能表现出截然不同的采样质量，性能结论不可直接跨平台套用。

五、回到标题：为什么云厂商纷纷布局ARM架构

中断模型的这段”补课史”，恰好解释了云计算厂商为何持续加码ARM架构产品，也说明了这条路为何需要长期投入。

能效比驱动的规模化需求。 云数据中心最敏感的成本项是每瓦性能。ARM架构在单位功耗上的计算密度具备优势，当规模达到数十万台服务器时，能效差异会被放大为可观的运营成本差距。这构成了最直接的商业动因。

架构定制空间。 云厂商希望按自身业务负载特征定制芯片，而ARM的授权模式提供了这种弹性。从通用计算到特定负载加速，自研芯片可以把”为云而设计”落到实处，减少对固定产品路线的依赖。

软件生态的逐步成熟。 早期阻碍ARM进入数据中心的核心问题不是算力，而是软件栈的完备度——性能工具、编译器、运行时、发行版支持。中断与性能分析能力的补齐正是其中关键一环。当perf、调试器、崩溃分析等基础工具在ARM64上达到可用、可信的水平，迁移的隐性成本才真正下降。

竞争与供应链考量。 多元化的芯片来源有助于提升议价能力与供应韧性。对云厂商而言，ARM不仅是技术选择，也是战略布局。

需要强调的是，架构迁移从来不是”换芯片”这么简单。它要求从内核、虚拟化层、运行时到可观测性工具的全链路适配。中断模型的演进只是其中一个切片，却极具代表性：一个看似底层、晦涩的机制缺陷，会直接影响到开发者每天使用的性能分析工具是否可信。工具不可信，优化就无从谈起；优化无从谈起，新架构的性价比优势就无法兑现。

六、实践建议清单

面向正在或计划在ARM64上做性能工作的团队，可以按以下顺序建立方法论：

1. 先验证工具可信度：在目标平台跑一个已知热点分布的基准负载，确认火焰图与实际相符，再用于生产分析。
2. 建立多源观测：采样、计数、trace、日志四类数据互为校验，避免单一数据源误导决策。
3. 审视临界区设计：把中断屏蔽区间当作一等公民对待，测量其长度与频率，持续压缩。
4. 跟踪内核能力演进：伪NMI相关支持与内核版本、固件版本强相关，升级时同步评估可观测性收益。
5. 跨平台结论隔离：不同架构、不同代际平台的性能数据分开归档，不做直接横向比较。

ARM64在服务器领域的扩张是大势所趋，但”能用”与”好用”之间隔着大量类似的底层细节。理解中断屏蔽如何扭曲火焰图，不只是为了避免一次错误的优化，更是为了建立一种习惯：对工具输出保持审慎，对平台差异保持敏感。这正是一名资深开发者与一个只会看图的执行者之间的区别。