云厂商为何争相布局 ARM 架构服务器芯片

作者:快去debug2026.11.03 22:37浏览量:0

简介:本文从性能采样盲区切入,剖析 ARM 架构在服务器场景遭遇的中断屏蔽难题,梳理其历经多年演进补足不可屏蔽中断能力的历程,帮助开发者理解架构差异对性能分析的影响,掌握火焰图误判的排查思路。

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

最近几年,领先的云计算厂商纷纷加大在 ARM 架构服务器芯片上的投入,从自研数据中心 CPU 到推出基于 ARM 的通用计算实例,动作频频。这背后既有能效比与成本结构的考量,也有供应链自主化的战略意图。但在一片叫好声中,一个被长期忽视的架构短板正在浮出水面:ARM64 在中断处理模型上的历史欠账,直接影响性能剖析工具的可信度。

本文不讨论商业策略,而是聚焦一个具体而硬核的技术问题——性能采样中的”黑洞”现象,以及 ARM 架构为补齐这一能力所付出的漫长努力。

一、火焰图上的”假热点”:一个被误读的信号

如果你在 ARM64 服务器上跑过性能剖析,很可能见过这样的火焰图:大量 CPU 时间集中在 local_irq_enable() 这个函数上,看起来像是中断使能操作本身成了瓶颈。

某芯片架构官方博客曾这样描述这一现象:

用户经常抱怨大量 CPU 时间花在了 local_irq_enable() 上。这不是真正的瓶颈——性能监控单元(PMU)中断只是在 IRQ 重新使能时才送达,所以剖析器总是在这个函数处采样。

换句话说,火焰图在骗你。真正消耗 CPU 的热点代码,藏在一段中断被屏蔽的临界区里,剖析器根本采样不到。当内核执行 local_irq_disable() 进入临界区后,普通中断被屏蔽,包括 perf 采样依赖的 PMU 中断。如果热点恰好位于一段长时间关中断的区间内,采样信号无法送达,这段区间在火焰图上就成了”黑洞”。而 local_irq_enable() 之所以显得很热,只是因为 PMU 中断总是在中断重新放开的瞬间才被递送,剖析器便在那里完成了采样。

这不是 perf 的 bug,而是中断模型差异导致的系统性问题。

二、根源:ARM64 缺失的”不可屏蔽中断”

对比 x86 架构,问题就清晰了。x86 提供了 NMI(Non-Maskable Interrupt,不可屏蔽中断)。性能采样中断可以配置为 NMI,即便 CPU 处于关中断状态,NMI 依然能打断执行流、抓取现场。因此 x86 的火焰图不会出现上述黑洞。

而 ARM64 长期没有原生的 NMI。准确地说,ARM A-profile 架构的中断控制器 GIC(Generic Interrupt Controller)奉行一套”通过优先级实现一切”的管理哲学——分组、抢占、屏蔽,全部统一在优先级机制下。这套统一模型在嵌入式和移动场景下表现出色,因为那里对”绝对不可屏蔽”的需求并不强烈。但当服务器场景要求剖析工具在任何时刻都能可靠采样时,纯优先级屏蔽模型的局限性就暴露了。

这里需要区分两个概念:

  • 优先级屏蔽:高优先级中断可以抢占低优先级,但本质上仍受当前优先级掩码控制;
  • 不可屏蔽:无论当前处于何种屏蔽状态,中断都能送达。

ARM64 缺的是后者。

三、七年三代方案:一场漫长的补课

为补上这块短板,ARM64 社区经历了漫长的探索。从最初尝试利用现有硬件特性模拟 NMI,到引入伪 NMI(pseudo-NMI)机制,再到逐步完善中断控制器的硬件支持,前后跨越约七年、历经三代方案,邮件列表上的交锋不计其数。

一位资深内核维护者曾直言:

外面有太多坏掉的硬件,启用伪 NMI 时会痛苦地死机。

这句话道出了问题的另一面:架构能力的补齐不仅是软件问题,更依赖硬件行为的一致性。早期硬件在伪 NMI 路径上的实现差异,导致内核不得不加入大量规避逻辑,甚至在某些平台上默认关闭该特性以保证稳定性。

从技术演进角度看,这条路径大致经历了三个阶段:

  1. 软件模拟阶段:利用高优先级中断近似 NMI 效果,但无法真正穿透关中断区间;
  2. 伪 NMI 阶段:借助中断控制器的优先级机制,构造出可穿透普通屏蔽的中断路径,但对硬件行为有严格要求;
  3. 硬件完善阶段:新一代中断控制器逐步提供更明确的中断分类与屏蔽语义,使伪 NMI 的可靠性显著提升。

四、对开发者的实际影响

理解这一差异,对日常性能调优有直接价值:

  • 看到 local_irq_enable() 异常突出时,不要急于优化该函数,先怀疑是否存在长时间关中断的临界区;
  • 在 ARM64 上做性能剖析时,应确认内核是否启用了伪 NMI 支持,以及当前硬件是否可靠支持;
  • 跨架构对比性能数据时,需意识到采样偏差可能导致结论失真,必要时结合其他观测手段交叉验证。

一个简单的排查思路如下:

  1. # 查看内核是否启用伪 NMI 相关配置
  2. zcat /proc/config.gz | grep -i NMI
  3. # 检查中断统计,观察是否有异常集中的中断递送
  4. cat /proc/interrupts | head -20

如果伪 NMI 不可用,可以考虑使用基于硬件追踪的采样方式作为补充,或在关键临界区前后手动插入探针,缩小黑洞范围。

五、结语

云计算厂商布局 ARM 架构,看中的是能效比与规模效应。但架构迁移从来不是免费的午餐,性能剖析工具的可信度就是容易被忽略的隐性成本之一。ARM64 用七年时间、三代方案,才逐步补上 x86 生来就有的不可屏蔽中断能力。对于一线开发者而言,理解这段历史与背后的机制,能帮助你在火焰图前保持清醒——那些看似灼热的热点,有时只是架构局限投下的影子。