PGStudy-静默数据损坏SDC缓解-Farron工具

发表于 阅读次数： Waline： 本文字数： 9.8k 阅读时长 ≈ 36 分钟

Understanding Silent Data Corruptions in a Large Production CPU Population

期刊: (发表日期: 十月 23, 2023) 作者: Shaobu Wang; Guangyan Zhang; Junyu Wei; Yang Wang; Jiesheng Wu; Qingchao Luo
摘要翻译:
对SDCs的静默特性导致目前对SDCs的研究相对较少的特性做出介绍
对大型生产处理器——超过100万个处理器中的SDK进行了研究
1. 对某些处理器功能是否特别脆弱，以及他们对应用程序的潜在影响
2. 探究可信的SDCs的重复触发条件以及划分更难重现的SDCs
3. 缓解SDCs的挑战和机遇
对应SDCs的观察结果开发了Farron，依赖于优先级测试来检测高度可重复的SDCs
期刊分区:SOSP顶会
Local Link: Wang 等 - 2023 - Understanding Silent Data Corruptions in a Large Production CPU Population.pdf

文章四问

  • Q1: 为什么看? （推荐? 关联? 解决问题?）

    A1: 同门推荐，容错计算，SDC，提出了对SDC现有模型的挑战，并提出了更优的解决方式Farron

  • Q2: 文章写的什么? （创新点? 工具? 实现路径?）

    A2: 创新点是对现有SDC模型的挑战，使用工具是Pin插桩与OpenDCDiag

  • Q3: 效果如何? （效果图? 结果? 评价?）

    A3：在检出率，性能方面都有提升，评价还行，但有点缺乏创新

  • Q4: 感受怎样? （感受? 收获? 思考? 复看?）

    A4：了解了一种容错计算中出现的错误，了解了一些工具

场外信息

源码

  • 不开源

Introduction

近年来，CPU技术得到了快速发展，时钟频率更高，一个处理器附加了更多核心。一个经典的假设是处理器按照设计工作并产生可靠的计算结果。 然而，生产环境中确实会发生处理器故障。

一般的CPU故障都会导致两个不同的错误类型：

  1. 立即崩溃
  2. 静默报出错误的运行结果

说明了SDCs可能造成的危害，并通过实际工程中的应用举例说明SDCs的危害。

然后说明SDCs的处理难度，通过实际工程中的已有解决方案给出例子。

说明已有的SDCs研究进展，主要分为三类

  1. 理论上陈述SDCs的存在，但没有研究具体错误
  2. 通过人工故障注入而不是自然产生的SDCs，研究SDCs的影响和容忍技术
  3. 提供有关现实世界中的CPU-SDC案例的简要数据，但缺乏有关故障率，软件针状，发生模式等的详细测量和分析。

因此，目前对实际环境中的SDC的了解十分有限。

在这篇论文中作者调查了大量的生产处理器中的SDCs，是一直第一项定量评估和系统分析大规模生产环境中的SDCs现象的工作，主要贡献如下：

  1. 在大规模生产环境中评估SDCs：在32个月内对超过100万个处理器进行了SDC测试。除了提供故障率的总体统计数据外，我们还进一步分析微架构、测试时间等，影响故障率以及这些故障是影响单个核还是处理器内的所有核
  2. 调查SDCs的软件影响：识别了SDCs的脆弱功能，指出广泛涉及脆弱功能的工作负载可能会受到影响。揭示了现有模型的缺陷，指出对如浮点计算SDCs可能只会导致小幅损失而使得现有检测技术失效
  3. 分析SDCs的可重复性：指出一些SDCs具有高度可重复性，而一些SDCs旨在特定条件下触发
  4. 评估了SDCs的当前缓解实践：确定了一个巨大的设计空间，通过确定测试用例的优先顺序和开发专注于多线程的测试用例改善SDCs的测试。提出了SDCs对故障容限技术的挑战
  5. 提出SDCs的具体缓解方法：受上述观察的启发，提出了Farron，一种有效的缓解SDC的方法，它依赖于定期测试来识别那些高度可重复的SDCs。并通过测试用例优先级来提高这种方法的效率，它控制处理器的温度，以最大限度地减少那些可重复性较低的SDK的发生;如果处理器必须在高温下工作，则可以通过分配更长的测试时间来进一步在这两种方法之间做出权衡。其检出率更高而管理费用更低。

Motivation and Methodology 动机和方法

说明了论文说用到的硬件设施，重点在于环境变量的控制缩减，与硬件类型是否是国际主流类型。

在生产过程中的SDC实例

随着时间的推移，阿里云偶尔会发现错误率高于其他服务器。经过广泛调试以确定根本原因后，我们发现问题是由于处理器缺陷造成的。在这里我们提供一些例子。

  1. 在一种情况下，存储应用程序经常报告用户数据的检查和不匹配。经过数周的调试，我们发现机队中的一个处理器出现故障，并且处理器上的与检验和计算相关的指令间歇性地给出错误的结果。
  2. 在第二种情况下，我们还观察到检查和不匹配，但我们的调试揭示了不同的原因：客户端线程将数据及其检查和打包到缓冲区中，然后与守护进程线程共享该缓冲区。由于缓存一致性存在缺陷，守护进程线程有时会获得不一致的数据，从而导致检查和不匹配。
  3. 在另一种情况下，程序有时会触发断言失败。我们后来发现这是因为应用程序使用哈希图来管理其元数据，而故障处理器中有缺陷的哈希计算影响了其元数据服务。

这些案例促进作者进行这项研究

Toolchain 工具链

该工具链旨在检测与云工作负载相关的SDCs，其包含一个框架与633个测试用例，框架根据用户规范选择器要执行的测试用例，并控制其执行顺序、测试期间的资源分配。

测试用例是模拟云工作负载的程序，经过精心设计，同时考虑软件行为和硬件功能。大多数测试用例关注单个处理器功能，例如浮点计算、分支预测、缓存、核心之间的互连等。这些测试用例的复杂性差异很大：

  1. 有些测试用例在循环内执行特定指令。
  2. 有些调用库中的函数。
  3. 有些调用应用程序逻辑。

此外还尝试了为SDC检测设计的其他工具链，如OpenDCDiag作为补充，并在研究中获得了相同的观察结果。其在研究中起到了两个作用

  1. 提供了测试处理器功能的权威方法
  2. 在对故障处理器进行深入研究时，它充当受影响的工作负载模拟器

说明了在研究中将所有可疑处理器都送回了制造商确认了其故障

在另一方面，工具链可能并不完整，假阳性与假阴性都是可能出现的。

Study Process and Approaches 学习过程与方法

Figure1

我们在生产前和生产过程中进行大规模测试，以发现阿里云中的故障处理器。如图1所示，预生产测试在

  1. 工厂交付后（制造好的芯片运送到阿里云后）
  2. 数据中心交付后
  3. 系统重新安装后（机器投产前需要安装新的系统来服务）

进行。然后在生产中，机器将定期进行分组测试。每个组的测试持续约2周，整个机队的测试需要数月。

在这些大规模测试中，我们顺序执行工具链中的所有测试用例，并且每个测试用例都被分配由管理员指定的相同测试持续时间。我们自2021年1月开始此类测试，到目前为止，我们已经发现了数百个有故障的处理器。 在这些有故障的处理器中，我们对其中27个进行了广泛的实验，以进行更详细的分析（其他处理器已退回制造商）。具体来说，我们已经运行了数千万次测试，并从这些测试中收集了一万多条SDC记录，以了解它们对应用程序及其重复性的潜在影响。

实际环境中的SDCs

测试结果的简要介绍

Table1
Failure rate

​ Observation 1: 总体而言，在研究中，有万分之3.61的CPU会被确定导致SDCs

这说明SDK代表了一个普遍存在的问题，而不是“黑天鹅”事件，尤其是在具有大量处理器的集群中。

​ Observation 2: 预生产测试期间和常规测试期间观察到的故障率分别为万分之3.262和万分之0.348

然而，尽管进行了所有SDC测试，仍然能够遇到影响阿里云服务的SDC问题，如第2.2节中所讨论的。这可以归因于定期SDC测试和再现SDC的不确定性之间的窗口。 解决这个问题具有挑战性，因为频繁执行定期SDC测试是不可行的。因此如果一个服务需要高可靠性而不考虑SDC容错是不可行的。

​ Observation 3: 在阿里云团队中的所有微架构中确定了SDCs，这说明在新架构chip中的SDC率不会降低

这表明SDC是现代处理器的一个普遍问题。我们已经针对这些微架构测试了数十万个样本。如表2所示，不同微架构的故障率范围从万分之0.082到万分之9.29。潜在的原因可能是因为在测试方法的复杂度增加的同时电路的架构复杂度也在同步增加。

聚焦于故障处理器

Fault Processor

​ Observation 4:单个处理器故障可能会影响单个物理核或涵盖处理器内的所有核

在大约一半的故障处理其中，只存在一个有缺陷的物理核心，缺陷发生在只能由单个物理核心使用的组件中，例如算数单元。请注意多个硬件线程（也称为逻辑核）可共享单个物理单元，当这个物理和行有缺陷时，这些逻辑核都会受到影响，并且以相同的频率失败同样的测试用例

在另外一般有故障的处理器中，缺陷可能会因向所有的物理核心，这可能是因为缺陷发生在所有核心共享的组件中，例如中央处理器缓存。但对于在所有核的非共享组件中发生的故障也会使得不同核在不同频率下对同样的测试发生故障，有时他们之间频率的差距可能高达几个数量级。这里值得注意的是作者的数据与Google的有些出入，这体现了作者的测试方式在对核心之间的一致性上更好的检出率。

无论哪一个核心被识别为有故障，大公司都会退役整个有故障的处理器或隔离正台机器。然而，值得研究的是，继续利用故障处理器未受影响的核心的可行性问题。

Software Symptoms of SDCs SDC的软件症状

Impacted Workload 受影响的工作负载

Figure2

Observation 5: SDC在特定工作负载中出现的相当普遍，主要分布在以下五种情况

  1. arithmetic logic computation算术逻辑运算
  2. vector operation 向量操作
  3. floating point calculation浮点计算
  4. cache coherency 缓存一致性
  5. transactional memory 事务性内存

缓存一致性指的是在多处理器系统中，确保各个处理器缓存中的数据保持一致的机制。由于各个处理器可能会独立地从主内存读取数据并将其存储在自己的缓存中，因此可能会出现同一数据在不同缓存中存在不同值的情况。这种不一致性可能导致程序运行错误或不符合预期的行为。

缓存一致性主要涉及以下几个方面：

  1. 一致性协议：通过缓存一致性协议（如MESI、MOESI、MOESIF等），处理器之间协调何时更新或失效缓存中的数据，以确保一致性。
    • MESI协议（Modified, Exclusive, Shared, Invalid）是最常用的一种协议，它定义了四种状态来管理缓存行。
  2. 数据更新：当一个处理器修改缓存中的数据时，其他处理器需要被通知，以便它们可以更新或使其缓存失效，从而保持一致性。
  3. 性能考虑：虽然维护缓存一致性是必要的，但这也可能引入性能开销，因此设计缓存一致性机制时需要权衡性能和一致性的需求。

向量操作涉及对向量数据结构（如一维数组或列表）进行的各种计算和处理。这些操作在数学、物理和计算机图形学等领域中非常常见。

常见的向量操作包括：

  1. 加法：将两个向量对应元素相加。
  2. 减法：将一个向量从另一个向量中减去。
  3. 点积（内积）：计算两个向量的点积，得到一个标量。
  4. 叉积：计算两个三维向量的叉积，得到一个新的向量（仅适用于三维空间）。
  5. 标量乘法：将向量的每个元素乘以一个标量。
  6. 向量归一化：将向量转换为单位向量，保持其方向但使其长度为1。
  7. 长度计算：计算向量的欧几里得长度（模）。
  8. 向量拼接：将多个向量合并成一个更大的向量。

事务性内存，也叫做TrxMem是一种并发编程的技术，用于简化多线程环境中的共享内存访问。事务性内存允许多个线程以事务的方式对共享数据进行读写，类似于数据库事务。这样可以保证数据的一致性和完整性，同时减少锁的使用，从而提高并发性能。

事务性内存的基本含义是：

  1. 原子性：事务要么完全执行，要么不执行，确保不会出现中间状态。
  2. 一致性：事务执行前后，数据的一致性不应被破坏。
  3. 隔离性：多个事务并发执行时，互不干扰，给用户呈现出一个独立的环境。
  4. 持久性：一旦事务完成，其结果应是持久的，通常与数据存储有关。

对于问题为何会出现在这五种功能上，作者给出了两种解释：

  1. 这些功能复杂程度高，更容易出现错误
  2. 其他功能大量被操作系统调用，当这些功能出错时，大概率并不会出现SDC，而是直接崩溃

图2显示了每个功能的故障处理器的比例。请注意，这些比例之和大于1。这是因为缺陷可能发生在多个功能的共享或集成组件上，因此一些处理器可能会在多个功能之间遇到错误。

进一步将SDCs分化为两种类型：

  1. Computation 计算型 包括算术逻辑运算，向量操作，浮点计算
  2. Consistency 一致性 包括缓存一致性，事务性内存

作者区分这两种类型有以下两个原因：

  1. 它们需要不同的测试策略，因为具有一致性类型的SDCs只能通过多线程测试检测。
  2. 如果一个处理器有多个缺陷功能，那么它们总是属于一种类型。在我们广泛测试的27个故障处理器中，19个处理器存在计算缺陷，其余处理器存在一致性缺陷。

由于测试用例都是基于模拟现实负载而设计的，因此可以进一步推测这些SDCs对现实工作负载的潜在影响。

作者试图查明哪些指令使存在问题的，但事实证明这是一项具有挑战性的任务。对于其中一些错误，工具链会保留上下文并指出不正确的指令，但这些错误通常很难重现，因此作者找不到合适的方式去调整测试用例以获得更多信息。

因而作者转向另外一种方法：

通过指示工具链去通过Pin捕获每个测试用例期间每种类型的指令执行次数。这种方式可以帮助缩小可以指令的范围。

例如，对于一条浮点计算复杂数学函数（arctangent）的命令在FPU1与FPU2中是可疑的，因为使用该指令的所有测试用例都可以重现SDCs，相反不使用则都可以通过

然而这种方式同样存在问题，即并非所有的错误都会有明显的可疑指令，在CNST1中的SDCs会导致缓存一致性问题，但由于缓存一致性机制通常对程序隐藏因程序通常不会调用特定指令来实现它。

值得注意的是，并非所有执行有缺陷的指令的测试用例都会引发错误，例如，在MIX1中，作者发现有缺陷的指令用于七个测试用例，但只有其中的两个会发生错误，在后续作者详细研究了触发条件。

Error Breakdown in Mis-calculated Data 错误计算数异常的分解

Figure3
Figure 4
Figure 5
Figure 6
Figure 7

作者进一步研究计算了SDCs的属性，以了解缺陷功能对工作负载结果的影响，作者在这一小节中将consistency SDCs排除在外，因为这些SDCs没有确定的模式。

​ Observation 6:SDCs已被证实会影响所有测试数据类型的操作，包括integer，single- and double-precious floating-point number，其中对浮点数操作相关的影响强调了SDCs的危害性

图3显示了涉及每种操作数据类型的故障处理器的比例。我们发现所有正在测试的数据队列都会受到SDK的影响，并且浮点数据队列比其他数据队列涉及更多的故障处理器。作者推测潜在的原因可能有以下两个：

  1. 许多不同的脆弱功能都与浮点计算相关，包括具有浮点数据序列和特定向量计算的向量操作。
  2. 三角函数等一些浮点运算比较复杂，增加了相关处理器功能设计和测试的难度。

​ Observation 7: 对于浮点数，SDCs导致的位反转通常发生在分数部分，导致轻微的精度损失

对于计算型的SDCs，图4a-b显示了在不同的数据类型中哪些位可能挥发升位反转现象。可以观察到位反转很少发生在最重要的位上，并且需要注意 ，这种位反转模式不适用于非数字数据，在图5中显示了非数字数据的每一位几乎都有相同的反转量。

此外，总体上并没有向特定值（0/1）反转的趋势，在特定的案例中，如MIX1的16位整数数据中，72.27%的位都是向0反转到1的。

在浮点数的标准当中，位都被划分位三个部分：符号，指数，分数。位反转通常命中分数部分。潜在的原因如下

  1. 分数的计算逻辑更加复杂
  2. 许多位反转集中在数据中间部分，并逐渐向末端减少

在图4（e）- 4（h）中显示了预期数据和实际数据之间的相对精度损失。由于观察到的位翻转主要发生在分数位中，因此浮点数据库的精度损失很小。例如，扩展双精度（80位）浮点数的所有精度损失都小于0.002%。双精度（64位）浮点数上99.9%的精度损失小于0.02%。80.25%的单精度（32位）浮点数的精度损失小于5%。另一方面，32位整数数据的精度损失有40.2%大于100%。

​ Observation 8: 对于特定的失败案例测试（测试用例与处理器的组合），位反转往往会在数字表示内的固定位置出现

作者将位反转模式定义为一组位翻转可能发生在输入（特定测试用例与处理器的组合）中的位置。通过将预期结果与实际结果的异或值来表示翻转位置，如果5%以上的SDC记录出现了相同的掩码，则将该掩码视为位翻转图案。在实际中，一个输入模式可能存在多个位翻转模式，潜在的原因是测试用例中的多个指令受到缺陷的影响，并且这些缺陷不能稳定的再现。图6中记录了某些输入设置下具有位翻转模式的SDC记录，这种模式出现的潜在解释是：位翻转往往受特定故障处理器硬件的固定影响，因此往往发生在固定位置。

作者进一步研究了位翻转发生在不同数据类型下的数量，可以发现在大多数情况下位翻转都仅仅发生一个位上

当前故障模型的缺陷：当前的故障模型假定

  1. SDCs是少见的，多个翻转的位是不太可能发生的事件
  2. 每个位置上的翻转都是独立同分布的（IID）

但根据作者的观察，对当前的SDC故障模型提出了挑战，并提出了改进的领域

  1. 位置偏好：在某些数据类型中，位翻转往往不会发生在最重要的位（Observation 7）
  2. 位翻转之间具有相关性：造成一些SDCs导致多个位发生位翻转（Observation 8）

需要更进一步的研究来研究该模型的应用含义，尽管浮点数的准确性损失似乎较小，但在某些对可靠性要求较高（金融，自动驾驶）主张使用更可靠的数据，可以考虑这些位翻转模式设计编码标准来提高数据可靠性。

SDCs的可重复性

Figure 8

当识别出一个中央处理器可能会在测试用例中失败后，作者通过对一组测试用例与处理器的搭配来了解问题的可重复性，作者使用发生频率：即每分钟的错误数量来衡量可重复性。

​ Observation 9: 一些SDCs具有高度可重复性，对应用产生了很大的影响。

SDC的发生频率在不同的设置中存在显着差异，从低至每分钟0.01次到高至每分钟数百次。在51.2%的设置中，出现频率高于每分钟一次。 某些SDCs的高重复性以及现有系统的设计不适合容忍SDCs的事实意味着这些SDCs可以在生产中快速、重复地表现出来。这就说明即使SDCs出现的概率很低，但它仍然可以造成巨量的损失，尤其是当它们无法被及时的检查到的情况下。

​ Observation 10: 在那些可重复性较差的SDCs中，温度是重要的SDC触发条件。在某些情况下，SDCs的出现频率随着气温升高而呈指数级增长。此外，发生频率与不同故障处理器和工作负载的最低触发温度相关。

作者研究了温度与SDCs发生频率的关系，发现即使在正常工作负载的温度下，温度越高仍然会导致SDCs的出现频率增加。作者通过一些工作负载的自然升温，或linux ‘stress’ cmd command将处理器预热到指定温度。

通过取SDC出现频率的以10为底的对数值，我们发现该值与我们27个处理器中的6个处理器的核心温度呈线性关系

图8（a）- 8（c）显示了一些故障处理器的这种关系，其Pearson相关系数大于0.75，证实了温度与SDC发生频率之间的指数相关性。

Pearson相关系数（Pearson Correlation Coefficient）是用于衡量两个变量之间线性关系强度和方向的统计量。它的值范围在-1到1之间：

  • 1：表示完全正相关，意味着一个变量增加时另一个变量也完全增加。
  • -1：表示完全负相关，意味着一个变量增加时另一个变量完全减少。
  • 0：表示无相关关系，两个变量之间没有线性关系。

计算公式

Pearson相关系数 rrr 的计算公式为：

\(r = \frac{n \sum (xy) - \sum x \sum y}{\sqrt{(n \sum x^2 - (\sum x)^2)(n \sum y^2 - (\sum y)^2)}}\)

其中：

  • \(n\) 是数据点的数量
  • \(x\) 和 \(y\) 是两个变量的观测值

应用

Pearson相关系数常用于：

  • 数据分析：评估变量之间的关系，常见于科学研究、经济学和社会科学。
  • 回归分析：作为初步分析工具，帮助判断模型的适用性。

最小二乘法（Least Squares Method）是一种数学优化技术，用于通过最小化误差的平方和来拟合数据模型。这种方法通常用于回归分析，帮助确定一条最佳拟合线，以描述自变量和因变量之间的关系。

主要概念

  1. 误差：指观测值与模型预测值之间的差异。最小二乘法的目标是找到一个模型，使得所有观测值与预测值之间的误差的平方和最小。

  2. 目标函数：在简单线性回归中，目标函数可以表示为：

    \(S=\sum_{i=1}^n(y_i−(mx_i+b))^2\)

    其中，\(y_i\) 是实际观测值，\(mx_i + b\)是模型预测值，\(m\) 是斜率，\(b\) 是截距。

  3. 参数估计：通过对目标函数 \(S\) 求偏导数并设为零，可以求解出最优的 \(m\) 和 \(b\)。

此外，作者观察到，在一些设置中，仅当温度超过某个特定阈值后才会发生SDCs。作者列出了几种在研究过程中困惑不已后来被证明是温度造成的问题案例：

  1. 其他内核行为：某一个内核会在其他内核繁忙时才发生错误，其出现频率随着繁忙内核数量的增加而增加。这很难理解，因为有缺陷的组件不会在内核之间共享。进一步研究发现，这些内核共用冷却装置，导致缺陷内核在其他内核繁忙时达到较高的温度。
  2. 余热：观察到一个故障处理器根据测试顺序产生错误。例如，当测试用例X在测试用例Y之前执行时，测试用例Y中会出现错误，而颠倒测试顺序则不会出现错误。后来发现，测试用例X对处理器施加了很大的压力，并产生了相当大的热量，导致测试用例Y的测试温度在仅执行测试用例Y。
  3. 工具链更新：在更新以使用更高版本的检测工具链之后，故障处理器中一些SDC的出现频率降低，这是令人惊讶的，因为更新没有修改测试用例的逻辑，我们也没有改变任何其他测试配置。进一步调查发现，更新后的工具链使用了更高效的框架，从而减少了产生的热量。

作者还发现：在前面提到在运行同一可能导致错误的指令的不同测试用例下，有些可能会导致错误，而其他的一些则不会导致错误。进一步的研究发现指令使用压力是其背后的原因。

为区分热量与指令运行压力的影响：对一些未接受测试的核心使用压力工具链，同时对目标核心执行测试工作负载。在本实验中，由于热量主要由stress工具链产生并由冷却装置消散，因此测试工作量对温度影响很小。通过这种方法，可以在温度几乎保持不变的情况下提高故障处理器的中央处理器利用率，并且观察到具有高中央处理器利用率的SDCs的出现频率更高。

  • 使用多种策略缓解SDC
Figure 9

作者进一步探索通过以协调和互补的方式结合多种策略来缓解SDCs的设计空间。图9说明了SDCs的最低触发温度与其在最低触发温度下出现频率之间的关系。 我们对发生频率的对数值和最低触发温度的值进行线性匹配，得出Pearson相关系数为-0.8272，这表明相关性相对较强。

作者根据上面的数据将SDCs分位两种类型：

  1. 显眼的 ‘Apparent’
  2. 棘手的 ‘Tricky’

不同类型的SDCs适合不同的策略

  1. 显眼的SDCs可以在闲置温度附近观察到，并且表现出很高的出现频率，使其更适合SDC测试。
  2. 棘手的SDCs可以通过控制温度来缓解此类SDC

现有策略的修改

主动SDC测试

​ Observatio 11: 在数万个处理器的生产环境中，633个测试用例中有560个没有检测到任何错误

虑到芯片制造商和云供应商等公司可能拥有大量历史数据来指导测试，这促使我们提出了以下优先级测试的建议：

  1. 在预生产测试中，由于测试资源充足，每个测试案例都可以得到全面测试;
  2. 在测试资源有限的定期测试中，我们可以为在预生产测试或早期定期测试中发现SDCs的测试用例赋予更长的持续时间。

作者使用的工具链并未公开，而推荐OpenDCDiag或SiliFuzz工具

SDC的检测和容忍

在SDC生成之前执行主动检测不同，存在多种方法来在生成后检测SDC。

​ Observation 12: 当面对中央处理器SDCs时，现有故障容忍技术的有效性会降低。

  • Checksum and parity 校验和和奇偶校验

端到端校验和被广泛用于检测数据路径中的数据损坏和验证数据完整性。

  1. EC主要用于恢复丢失的数据，但不用于检测损坏的数据。
  2. ECC和CRC在计算奇偶性时假设数据是正确的，并且随后可以检测数据或奇偶校验位中的位翻转，但是CPU SDC可能在计算奇偶性之前生成错误的结果，并且在这种情况下，这些技术可能生成与已经被破坏的数据匹配的奇偶性。
  3. 即使在生成奇偶校验之后发生损坏，标准ECC也只能纠正单个位翻转错误并检测两个位翻转错误，但我们的研究表明多个位翻转错误是可能的(Observation 8)。
  4. 更糟糕的是，其中一些检查和算法严重涉及易受攻击的功能，这意味着它们更容易受到中央处理器SDK的影响。例如，EC和CRC都严重涉及向量操作，这是脆弱的特征之一（Observation 5），以加速计算。
  • Redundancy 冗余

它们在多个副本上执行相同的逻辑，并比较它们的结果以检测甚至纠正错误。冗余也可以通过硬件来实现，例如使用DCollins（双核锁步）技术。然而，考虑到中央处理器的低故障率，此类技术成本太高，无法应用于每个应用程序，尽管它们可能适合少数关键应用程序。

  • Prediction 预测

使用机器学习模型来预测SDCs的出现。其中一部分预测结果的范围，并在实际结果超出此范围时断言无声错误[29-31]。然而，真正的SDCs可能会有轻微的精度损失（Observation 7），这使得这些方法难以确定检测SDCs的狭窄范围。另一方面，这样的轻微损失是否可以接受是一个需要进一步调查的话题

Farron: An Efficient SDC Mitigation Tool Farron：高效的SDC缓解工具

Figure 10
  • Baseline

阿里云使用的现有策略通过进行主动SDC测试来减轻SDC的影响，这通过在故障处理器生成SDCs之前识别和删除故障处理器来帮助防止SDC的影响。总而言之，SDC测试在生产前和生产期间每三个月进行一次，在每一轮测试中，所有测试用例都顺序执行，并分配平等的测试资源。对于一个核心被检测到有缺陷的处理器，阿里云将弃用整个处理器。

Design 设计

由于SDC测试的局限性，根据我们从观察10获得的见解，Farron使用温度控制作为SDC测试的补充。为了确定何时启动温度控制和何时应用SDC测试，Farron建立了一个温度边界，该边界适应应用程序的实际运行条件。

图10说明了Farron工作流，该工作流在三种状态下运行：Pre-Products、Online和Suspect。在投产前状态期间，将使用足够的资源执行SDC测试。在在线状态下，用户应用程序在通过SDC测试证明可靠的核上执行，并在Farron控制的触发条件下运行。在这种状态下会定期进行SDC测试，以实现长期保护。在SDC测试失败的情况下，Farron针对可疑处理器执行深入的SDC测试，并根据测试结果的分析调整可靠的资源。

  • Adaptive temperature boundary 适应性温度边界

Farron将最高优先级分配给应用程序性能，从而最大限度地减少频繁使用工作负载回退。为了实现这一点，Farron区分了冷却设备操作和工作负载退避的温度边界，并使工作负载退避的边界自适应。Farron使用一个窗口来跟踪最近的温度监测记录，如果窗口内超过一半的温度记录超过当前边界，则提高工作负载回退的温度边界，表明温度在给定情况下应用的正常工作范围内。通过迭代增加温度阈值，法伦自主学习标准工作温度，从而防止过度使用工作负载回退。如果不到一半的温度记录超过当前边界，则将触发工作负载回退，直到温度低于边界。 Farron根据该自适应温度边界进一步调整定期测试持续时间，遵守观察结果10中概述的模式（即，较低的温度边界条件将分配更少的测试持续时间）。

  • Efficiency-focused SDC testing 以效率为重点的SDC测试

Farron试图通过利用与测试用例优先级、目标功能和测试环境相关的见解来提高SDC测试效率（观察5、10和11）。

建立三个不同的优先级：基本、活动和可疑。“基本”优先级被分配给测试用例，尽管测试用例是为特定功能而设计的，但在我们的大规模测试中却无法检测到错误。“主动”优先级被指定为测试用例，这些测试用例具有成功识别缺陷特征的已证明的跟踪记录。最后，“可疑的”优先级只分配给在当前处理器的核上检测到错误的测试用例。

Farron主要将测试资源分配给受保护应用程序使用其目标功能的测试用例，重点关注那些标记为“可疑”(如果有)和“活动”的测试用例。其余的测试用例以尽力而为的模式进行测试，确保采用全面而高效的测试方法。此外，我们非常重视测试环境。Farron通过运行burn-in工作负载来启动测试，并同时测试处理器中的每个内核，以在测试期间提高内核温度(观察10)。

  • Fine-grained processor decommission 细粒度处理器退役

最初，Farron通过对识别出缺陷的核心执行充分的测试来积累具有“可疑”优先级的测试用例。通过针对这些“可疑”测试用例进行充分的SDC测试，Farron可以有效地验证剩余核心的功能（观察4）。如果发现处理器内有两个以上的核心有缺陷，Farron将根据观察4中提出的模式弃用整个处理器。

Evaluation 评估

Figure 11
Table 4

图11显示了SDC在一轮测试中的覆盖率，其定义为故障处理器中检测到的错误与已知错误总数的比率。如图所示，Farron的覆盖率高于基线。在开销方面，Farron的平均一轮常规测试时长为1.02小时，而基线为10.55小时。

Conclusion 总结

在这篇研究论文中，对大型生产环境中的中央处理器SDC现象进行了全面调查，并进行了测量和分析。研究涉及多个角度，包括车队维护、软件症状、发生模式和SDK的当前实践。进一步提出了12个观察结果，阐明了它们对系统的影响。随后，提出了一种名为Farron的具体缓解方法，该方法说明了如何利用本次研究来改进现有的缓解策略。