CPU 一直都不是完全可靠的，自问世以来就一直存在消失过失的风险。这些风险不仅来源于设计上的一些疏忽，也源于环境条件和会产生妨碍的物理系统。但这些过失往往很少见，如果系统按预期运行，则只有极少部分算计会消失过失。大多数情况下，算计机芯片被视为值得信赖的。
然而，最近google和 Facebook 两大公司频繁检测到 CPU 消失一些「不当行为」，以至于他们正在敦促技术合作公司找到找出这些过失并补救的步骤。
google工程师 Peter Hochschild 在近日刚刚举办的 HotOS 2021 上说道：「生产团队抱怨『呆板破坏数据』的情况越来越多。」他表示：「这些呆板被指控破坏了多个不同的、稳定的、调试良好的大型应用程序。呆板都被各个独立团队反复指责，并且这些指控是可信的。但传统的诊断步骤没有发觉它们有任何课题。」
开发者们更深入地查看了所涉及的代码和来自相关呆板的操作遥测，google工程师开始怀疑是硬件存在课题。他们调查发觉硬件过失的发生率高于预期，这些课题在安装后很长时间内偶尔会消失，并且消失在特定的单个 CPU 内核上，而不是整个芯片或一系列部件上。
google的研讨职员检查了这些寂静损伤执行过失 (corrupt execution error，CEE) 后得出结论：这些过失应该归咎于「易变的内核（mercurial core）」——CPU 在一些情况下偶尔会以一种无法预测的方式消失算计过失。
这些过失不是因为像 M1 芯片一样的架构设计失误，而且在制造尝试期间也没有检测到这些课题。相反，google工程师认为，之所以会消失过失，是因为我们已经将半导体制造推向了妨碍变得更加频繁的地步，而我们缺乏提前辨认妨碍的工具。
在一篇名为《Cores that don’t count》的论文中，Hochschild 及其同事列举了算计机内核的不可靠性现在才受到关注的几个原因，包括大型服务器机群能够让罕见课题更加明显、开发者们近来才更加关注整体可靠性和降低软件过失率的相关改进。
论文地址：https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s01-hochschild.pdf
但该研讨表示有一个更根本的原因：「越来越小的特征尺寸越来越接近 CMOS 缩放的极限，并且架构设计的复杂性也在不断增加。」并指消失有的验证步骤并不适用于发觉偶尔消失的缺点或部署后物理损伤的结果。
我们习惯于将算计机视为妨碍停止装置，尤其是执行指令的内核，而大多数系统软件都依赖于这种假设。随着芯片制造朝着更小的特征尺寸和更精细的算计结构发展，并且随着引入新的复杂指令集以提高性能，我们发觉了在制造尝试期间没有检测到的算计过失。这些缺点不能总是通过微代码更新等技术来缓解，并且这些缺点大概与处理器内的特定组件有关，允许小型代码更改大概会影响可靠性。更糟糕的是，这些过失通常是悄无声息的——唯一的变现就是消失算计过失。
这种「易变」的内核极为罕见，但在大量服务器中，我们则可以观察到它们造成的中断，甚至足以将它们视为一个明显的课题。这意味着需要硬件设计职员、处理器供应商和系统软件架构师之间合作解决这种缺点课题。
此外，google的研讨者提出了一些缓解该课题的步骤，例如辨认和去除「易变」内核。
「易变」内核的辨认具有挑战性，因为「易变」内核大概导致妨碍和数据损伤、而不当的辨认大概会导致良好内核的浪费，并且辨认过程的成本也很高。该研讨对「易变」内核的辨认过程进行了分类，包括：
自动化与人工；
部署前与部署后；
线下 vs. 线上；
基础设施级别与应用级别。
不过，辨认和去除「易变」内核并不总是能避免影响应用程序，并且辨认大概不是完美的。因此google的研讨者提议设计能够容忍 CEE 且没有过多开销的软件？这将从以下几点出发：
对特定于应用的机制施加一些负担，应用「端到端 Argument」设计思想，这种思想指出正确性通常最好是在端点而非较低级别的基础设施中进行检查。
系统应该支持高效的检查点，通过在不同的内核上重新启动，以将失败的算计重新恢复。
使用面向应用的成本高效检测步骤来决定是继续通过检查点还是重试。例如，在提交之前算计数据库记录的不变量以确认呆板是否损伤了数据。
Facebook 也发觉了同样的课题
无独有偶，Facebook 也注意到了这些过失。今年 2 月，Facebook 发表了一篇名为《 Silent Data Corruptions at Scale 》的论文，论文中写到，与之前观察到的数据中心相比，寂静数据损伤（SDC）正在成为一种更加普遍的现象。SDC 不能通过中央处理单元（CPU）中的过失报告机制捕获，因此无法在硬件级别上进行跟踪。但是，数据损伤在整个堆栈中传播，并表现为应用程序级课题。这些类型的过失大概导致数据丢失，并且大概需要数月的调试工程时间。
在本文中，研讨者描述了导致 SDC 的硅制造过程中常见的缺点类型。讨论了一个数据中心应用程序中寂静数据损伤的真实示例。并提供了一个调试案例，以通过案例研讨来跟踪 CPU 中的根本原因和对过失指令进行分类，以举例说明如何调试此类过失。研讨者提供了缓解措施的高级概述，以减少大型生产团队中无提示数据损伤的风险。
论文虽然提出了缓解策略，但没有解决根本原因。
论文地址：https://engineering.fb.com/2021/02/23/data-infrastructure/silent-data-corruption/
图 2 以图形形式显示了数据库的损伤和链接。
图 3 提供了一个高级调试流程，用于追踪导致根本原因的寂静过失。损伤也会影响非零的算计。例如，在被辨认为有缺点的呆板上执行了以下不正确的算计。研讨发觉算计会影响特定数据值的正负幂，并且在某些情况下，结果应该为零时却非零。以不同的精度获得了不正确的值。
过失示例
在google的研讨职员看来，Facebook 发觉了寂静过失，但是找出过失原因并解决它，还需要进一步的工作。
不正常的内核带来的风险不仅包括崩溃（现有的过失处理妨碍停止模型可以适应这种情况），还涉及过失算计和数据丢失，这些课题大概被忽视，带来风险。
Hochschild 讲述了一个例子，「我们的一个 mercurial cores 破坏了加密，只有它才能解密自己过失加密的内容。」google的研讨职员以「商业原因」拒绝透露其数据中心检测到的 CEE 率，但他们提供了一个大致的数字，即大约是每几千台呆板有几个 mercurial cores，与 Facebook 报告的比率类似。
理想情况下，google希望看到自动辨认 mercurial cores 的步骤，并建议在芯片的整个生产周期中进行 CPU 尝试，而不是仅仅依赖于部署前的老化尝试。目前，google依赖于人工驱动的内核完整性审查，但这种方式并不是特别准确，辨认可疑内核的工具和技术仍在进行中。
google的研讨职员解释说，「根据我们最近的经验，通过人工驱动审查发觉的可疑性过失，大约有一半是被证实的，我们必须通过进一步的尝试 (通常是在首先开发一种新的自动尝试之后) 来提取『证据』」。另一半是虚假指控和有限的可复现性。
参考链接：https://www.theregister.com/2021/06/04/google_chip_flaws/