CPU一直没有完全可靠，从诞生之初就存在出错的风险。这些风险不仅来自设计疏忽，还来自可能发生故障的环境条件和物理系统。但这些错误往往很少见，如果系统按预期运行，则只有很小一部分计算会出错。在大多数情况下，计算机芯片被认为是值得信赖的。然而，最近，谷歌和Facebook频繁检测到CPU“不当行为”，以至于他们敦促技术合作伙伴找到发现和修复这些错误的方法。谷歌工程师PeterHochschild在最近举行的HotOS2021上表示：“生产团队越来越多地抱怨‘机器破坏数据’。”他说：“这些机器被指控破坏了多个不同的、稳定的、调试良好的大型应用程序。这些机器被各个独立团队多次指责，指控是可信的。但传统的诊断方法并没有发现它们有任何问题。”开发人员对涉及的代码和来源进行了更深入的研究，根据对相关机器的运行遥测，谷歌工程师开始怀疑硬件存在问题。他们的调查发现，硬件错误的发生率高于预期，这些错误在安装后很长时间内偶尔会出现，并且发生在特定的单个CPU内核上，而不是整个芯片或一系列部件。谷歌研究人员检查了这些静默的腐败执行错误（corruptexecutionerror，CEE）并得出结论认为它们应该归咎于“易失性核心（mercurialcore）”——CPU在某些情况下偶尔会以不可预知的方式发生计算错误。这些错误并非像M1芯片那样由于架构设计错误，在制造测试中也没有发现问题。相反，谷歌工程师认为错误的发生是因为我们已经将半导体制造推向了故障变得更加频繁的地步，而我们缺乏提前识别故障的工具。在一篇名为《Cores that don’t count》的论文中，Hochschild及其同事列举了计算机内核的不可靠性现在才受到关注的几个原因，包括大型服务器群可以使罕见问题更加明显，以及开发人员直到最近才更加关注总体可靠性和相关改进，以降低软件错误率。论文地址：https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s01-hochschild.pdf但该研究称还有一个更根本的原因：“越来越小的特征尺寸越来越多，越来越接近CMOS缩放的极限，架构设计的复杂性也在增加。”并指出现有的验证方法不适合发现偶然的缺陷或部署后物理损坏的结果。这个假设。随着芯片制造向更小的特征尺寸和更精细的计算结构发展，以及引入新的复杂指令集以提高性能，我们发现在制造测试期间未检测到的计算错误。这些缺陷并不总是可以通过诸如以下的技术来减轻微代码更新，并且由于这些缺陷可能与处理器内的特定组件有关，允许小的代码更改可能会影响可靠性。更糟糕的是，这些错误通常是无声的——唯一的表现是计算错误。这种“易失性”内核极为罕见，但在大量服务器中，我们可以观察到它们造成的中断足以甚至考虑r他们是一个明显的问题。这意味着需要硬件设计师、处理器供应商和系统软件架构师之间的合作来解决此类缺陷。此外，谷歌的研究人员还提出了一些方法来缓解这个问题，比如识别和移除“易失性”内核。“易失性”内核的识别具有挑战性，因为“易失性”内核会导致故障和数据损坏，不正确的识别会导致良好内核的浪费，而且识别过程的成本也很高。该研究对识别“易变”内核的过程进行了分类，包括：自动与手动；部署前与部署后；离线与在线；基础架构级别与应用程序级别。然而，识别和移除“易失性”内核并不总能避免影响应用程序，并且识别可能并不完美。所以Google的研究人员提议设计可以容忍CEE而无需过多开销的软件？这将从以下几点开始：对特定于应用程序的机制施加一些负担，应用“端到端论证”设计理念，该理念指出正确性通常最好在端点而不是在较低级别的基础设施检查中完成。系统应该支持有效的检查点，以通过在不同的核心上重新启动来恢复失败的计算。使用面向应用程序的、具有成本效益的工具来决定是继续通过检查点还是重试。例如，计算数据库记录的不变量以查看机器在提交之前是否损坏了数据。并非巧合的是，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提供了一个高级调试流程，用于跟踪导致根本原因的静默错误。腐败也会影响非零计算。例如，以下不正确的计算是在一台被识别为有缺陷的机器上执行的。已经发现，计算会影响特定数据值的正负幂，在某些情况下，结果应该为零时却不为零。以不同的精度获得了不正确的值。错误示例据谷歌的研究人员称，Facebook发现了一个静默错误，但还需要进一步的工作来确定错误的原因并修复它。不健康的内核带来的风险不仅包括崩溃（现有的错误处理故障停止模型可以解决），还包括计算错误和数据丢失，这些可能会被忽视并带来风险。Hochschild讲述了一个例子，其中“我们的一个mercurial核心破解了加密，只有它能够解密它错误加密的内容。”谷歌的研究人员拒绝透露在他们的数据中心检测到的CEE率，理由是“商业原因”，但他们提供了一个粗略的数字，大约是每几千台机器几个mercurialcores，这与Facebook报告的比率相似。理想情况下，谷歌希望看到自动识别Mercurial内核的方法，并建议在芯片的整个生产生命周期中进行CPU测试，而不是仅仅依靠部署前的老化测试。目前，谷歌依赖于人为驱动的内核完整性审查，但这种方法并不是特别准确，识别可疑内核的工具和技术仍在进行中。谷歌的研究人员解释说，“根据我们最近的经验，大约一半通过人工审查发现的可疑错误得到确认，我们必须通过进一步的测试（通常是在首先开发新的自动化测试之后）来提取“证据””。另一半是诬告和有限的可复制性。
