操作系统论文导读（十八）：RTailor: Parameterizing Soft Error Resilience for Mixed-Criticality Real-Time Systems

不同的任务对软错误弹性的需求不同，例如，低关键性任务可能不需要软错误弹性，而中高关键性任务可能需要较高的弹性。然而，现有的软错误弹性方案无法细粒度地控制其弹性级别，只能在任务执行时整体开启或关闭。为此，本文提出了RTailor，一个由编译器指导的参数化软错误弹性方案，可以根据每个任务的需求提供所需的软错误保护级别。其核心思想是，对于给定的保护比率，编译器可以转换一个热循环，使其受保护的迭代次数与总迭代次数匹配。相比于全保护每次迭代的方案，RTailor的参数化软错误弹性显著减少了任务的性能开销，从而提高了其实时调度性。实验结果表明，对于四个代表性故障率，RTailor在平均调度性上比缺乏参数化软错误弹性的最先进工作提高了15%到21%。实验结果表明，对于四个代表性故障率，RTailor在平均调度性上比缺乏参数化软错误弹性的最先进工作提高了15%到21%。

总的来说，这篇文章的工作非常有意思，但是并没有看到MCS的任何性态，以及充分的响应分析

二、文章简介

背景与动机

软错误：软错误是任务执行期间因高能粒子撞击引起的错误，如宇宙射线。这些错误会改变寄存器和内存单元中的数据，而不会造成物理硬件损坏。软错误可能导致系统崩溃、挂起或数据损坏。
重要性：在关键任务嵌入式系统（如无人机）中，软错误可能导致严重后果。例如，飞行控制内核中的软错误可能导致发送错误信号给执行器，从而导致无人机坠毁。
现有问题：传统的软错误弹性方案（如指令冗余）在任务执行期间整体开启或关闭，无法细粒度地控制弹性级别。这会导致不必要的性能开销，从而影响任务的调度性。

RTailor 的提出

RTailor 是第一个实现应用定制软错误弹性的方法。它通过以下两种技术实现错误检测和恢复：

指令冗余：复制指令并比较原始指令和复制指令的输出。
幂等处理：将程序划分为无副作用区域，每个区域可以重新执行以纠正检测到的错误。

RTailor 仅对部分指令进行复制，以实现参数化软错误弹性。这种方法相比全复制方案显著减少了性能开销，从而提高了任务的实时调度性。

核心思想

热循环转换：RTailor 的编译器转换热循环，使受保护的迭代次数与总迭代次数匹配给定的保护比率。
保护比率：定义为热循环中受保护的迭代次数与总迭代次数的比率。对于热循环之外的指令，RTailor 仍然使用全保护方案。

实验与评估

实验结果：实验结果显示，对于四个代表性故障率，RTailor 在 NASA 并行基准测试（NPB）和 MiBench 应用中的调度性平均提高了15%到21%。
性能开销：RTailor 的参数化软错误弹性减少了任务的执行时间，虽然增加了代码大小，但影响较小。
改进：与现有的树形调度器相比，RTailor 提高了系统的调度性，并且实现了细粒度的软错误弹性控制。

热循环转换（Hot Loop Transformation）

热循环转换是RTailor系统中一个关键的技术，用于实现参数化的软错误弹性。这里的“热循环”指的是在程序执行过程中被频繁执行的循环部分。这些循环通常是性能瓶颈所在，因此在这些部分引入软错误保护时需要特别关注性能开销。

热循环转换的具体步骤：

分析热循环：

RTailor的编译器首先识别程序中哪些循环是“热循环”。这通常通过静态分析或运行时分析来确定哪些循环被频繁执行。

设定保护比率：

用户或系统设定一个保护比率（protection ratio），即在一个热循环中，多少比例的迭代需要软错误保护。例如，如果保护比率设定为50%，那么每执行两次循环迭代，其中一次会受到保护。

转换热循环：

编译器根据设定的保护比率，转换热循环的代码结构。例如，如果保护比率为50%，编译器会在每两次迭代中插入一次软错误保护代码。
具体实现可能涉及对循环体进行修改，添加条件检查或控制结构，以确保保护比率得以实现。

插入软错误保护代码：

对于需要保护的迭代，编译器插入相应的软错误保护代码。这些代码通常包括指令冗余（如复制和比较指令）和幂等处理（如重新执行无副作用的代码段）。

通过这种方式，RTailor能够在确保关键任务获得必要保护的同时，避免在整个循环中引入过多的性能开销。

保护比率（Protection Ratio）

保护比率是RTailor系统中的一个核心概念，用于定义在一个热循环中需要进行软错误保护的迭代次数相对于总迭代次数的比例。

保护比率的具体含义：

定义：
保护比率表示在一个热循环中，受保护的迭代次数与总迭代次数的比率。例如，保护比率为50%意味着在10次迭代中有5次受到保护。
选择保护比率：
不同任务对软错误保护的需求不同。高关键性任务可能需要较高的保护比率，而低关键性任务则可能不需要保护。通过设定不同的保护比率，RTailor能够针对不同任务的需求提供定制化的保护。
影响：
保护比率直接影响任务的执行时间和系统的调度性。较高的保护比率意味着更多的迭代受到保护，减少软错误的可能性，但也增加了性能开销。相反，较低的保护比率则减少了性能开销，但增加了软错误的风险。

三、动机与背景

A. 软错误弹性：检测与恢复 (Soft Error Resilience: Detection and Recovery)

软错误弹性一直是任务关键嵌入式系统中的一个重要研究领域，因为这些系统需要确保正确性和安全性。以下是软错误弹性的一些关键概念和方法：

软错误检测：
- 指令级双模块冗余（DMR）：一种常见的软件方法是指令级双模块冗余。这种方法在编译时复制程序的指令，并在同步点（如存储指令）注入检查代码，以便在运行时比较原始指令和复制指令的输出。这种方法被称为指令复制的错误检测，如果输出不匹配，则视为软错误。
降低运行时开销的硬件方法：
- 核心级双模块冗余（Core-level DMR）：在硬件层面进行错误检测，通过双模块冗余（DMR）和三模块冗余（TMR）等方法实现。尽管硬件方法可以减少运行时开销，但其缺点是高功耗和复杂的硬件逻辑，并且缺乏根据任务需求调整软错误弹性级别的能力。
- 声学传感器方案：利用声学传感器进行软错误弹性检测，也是一种硬件方法。
软错误恢复：
- 后向恢复（Backward Recovery）：例如，幂等处理（Idempotent Processing）将程序划分为一系列无写后读依赖（WAR）的幂等区域，每个区域可以重新执行而不影响最终结果。
- 前向恢复（Forward Recovery）：例如，SWIFT-R 运行程序的三个副本，并在同步点添加恢复代码，通过多数投票来纠正错误。InCheck 利用额外的寄存器/内存检查点，在检测到错误时利用检查点的值来决定错误是否可恢复。
粗粒度的方案：
- 进程级别的恢复：这种方法在进程级别进行错误检测和恢复，运行多个副本进程，并在所有进程之间进行多数投票来纠正错误。

尽管现有的方案提供了多种错误检测和恢复的方法，但它们大多无法在细粒度和应用定制的层面上调整软错误弹性。

双模块冗余（DMR）：

在DMR中，同一个任务同时在两个独立的处理器核心上执行。这两个核心会并行执行相同的指令集。
在执行过程中，这两个核心的输出会不断进行比较。如果输出不一致，则意味着检测到软错误。
通过这种方法，可以实时检测并纠正软错误。

三模块冗余（TMR）：

三模块冗余（TMR）是DMR的扩展，利用三个独立的核心同时执行相同的任务。
这三个核心的输出会进行多数投票（majority voting）。如果三个核心中有一个核心的输出与其他两个不一致，则可以通过多数投票确定正确的输出，从而纠正错误。

声学传感器方案是一种利用声学传感器进行软错误检测的硬件方法。

工作原理：

声学传感器可以检测芯片内部由高能粒子撞击产生的声波。
当高能粒子撞击芯片时，会产生微小的声波，这些声波可以被声学传感器捕捉到。
通过分析这些声波信号，可以检测到由于粒子撞击导致的软错误。

幂等处理是一种常用的错误恢复技术，通过将程序划分为无写后读依赖（WAR, Write-After-Read）的幂等区域，来实现错误检测和恢复。

工作原理：

划分幂等区域：

程序被划分为一系列幂等区域。每个区域内的代码可以在不改变最终结果的情况下重新执行。
无写后读依赖（WAR）：在这些区域内，没有写操作依赖于之前的读操作。这确保了重新执行时，不会因为数据依赖关系导致错误结果。

错误检测与恢复：

在执行过程中，如果检测到错误，可以通过重新执行幂等区域来纠正错误。
这种方法依赖于区域内的代码是幂等的，即多次执行结果一致。

B. 任务重执行以满足故障率要求 (Re-execution of Tasks to Meet Failure Rate Requirements)

混合关键性实时系统中的软错误弹性：
- 任务关键嵌入式系统必须具备软错误弹性，以防止潜在的灾难性故障。特别是在混合关键性实时系统中，每个任务都有实际故障率和要求故障率。
- 实际故障率（Actual Failure Rate）：表示任务在执行期间可能失败的概率，这受多种因素影响，包括程序特性、底层硬件和环境。
- 要求故障率（Required Failure Rate）：规定了在给定时间内允许的最大故障率。例如，DO-178C 规定了每个任务的故障率要求。
满足故障率约束：
- 调度器利用所有任务的实际故障率和要求故障率，以及它们的周期和最坏情况执行时间，来确定任务是否可调度。
- 对于那些不满足故障率约束的任务，即实际故障率超过要求故障率的任务，调度器可以通过重执行机制降低实际故障率。重执行机制的原理是，如果任务被多次执行，则其实际故障率会随着重执行次数的增加而降低。
重执行公式：
- 公式： $N_{\text{re-exec}} = \max(0, \left\lceil \log_{p_F} p_{\text{req}} \right\rceil - 1)$
- 解释：对于一个给定的任务，根据其实际故障率 $p_F$ 和要求故障率 $p_{\text{req}}$ ，计算满足故障率约束所需的最小重执行次数。
示例（图1）：
- 任务A的原始故障率为 $10^{-3}$ 每小时，要求故障率为 $10^{-7}$ 每小时。根据公式，任务A至少需要执行3次才能满足故障率约束（即 $N_{\text{re-exec}} = 2$ ）。
- 这种方法会导致处理器资源的3倍占用，因为任务A需要执行3次以达到所需的故障率。

C. 文章解决方案：参数化弹性 (Our Solution: Parameterized Resilience)

基于前面讨论的背景和动机，本文提出了RTailor，一个由编译器指导的灵活且高效的参数化软错误弹性方案，专为混合关键性实时系统设计。RTailor通过为每个任务提供定制的软错误弹性，避免了不必要的过度保护，从而显著提高了任务的可调度性。

RTailor的工作原理

定制化软错误弹性：
- RTailor允许为每个任务指定不同的软错误弹性级别。例如，任务A可以有40%的保护、80%的保护和完全保护（100%保护）。这种灵活性使得系统可以根据任务的关键性和需求提供适当的保护，而不是对所有任务都进行全保护。
减少过度保护：
- 图2展示了任务A在不同保护级别下的执行版本序列。例如，“full”（完全保护）、“80%”（80%保护）和“40%”（40%保护）。与非参数化的执行序列（“full”“full”“full”）相比，参数化的执行序列的实际故障率更高，但仍然满足故障率约束。
- 公式表示为： $p_A^{\text{req}} \geq p_A^F \cdot p_A^{80\%} \cdot p_A^{40\%} \geq (p_A^F)^3$
提高可调度性：
- 通过减少任务的过度保护，RTailor显著降低了任务的执行时间。这使得调度器有更多的空间来调度其他任务，从而提高了系统的整体可调度性。
实际应用示例：
- 图2展示了任务A在不同保护级别下的实际故障率。参数化保护允许任务A在满足故障率约束的同时，减少执行时间和处理器利用率。
- RTailor通过这种参数化弹性实现了任务保护的定制化和优化，提高了系统的性能和效率。

什么是参数化执行序列的实际故障率

参数化执行序列：

参数化执行序列指的是任务在执行过程中采用不同的保护级别。图2中，任务A有三个版本的执行序列：完全保护（full）、80%保护和40%保护。
每个保护级别表示任务中某些指令受到保护的比例。例如，80%保护意味着在执行任务时，80%的指令受到软错误保护。

实际故障率：

实际故障率是指任务在执行过程中可能失败的概率。不同的保护级别会影响实际故障率。例如，完全保护下的故障率最低，而部分保护下的故障率较高。
参数化执行序列通过组合不同的保护级别来实现。例如，“full”、“80%”、“40%”表示任务A先以完全保护执行一次，然后以80%保护执行一次，最后以40%保护执行一次。

为什么参数化执行序列的实际故障率更高但仍然满足故障率约束

故障率约束：

故障率约束是任务在特定时间内允许的最大失败率。例如，任务A的要求故障率 $p_A^{\text{req}}$ 可能是 $10^{-7}$ 每小时。
任务的实际故障率必须小于或等于这个要求故障率，才能满足故障率约束。

参数化执行序列的实际故障率：

参数化执行序列的实际故障率较高，是因为部分保护级别（如80%和40%）比完全保护的故障率更高。但通过组合不同的保护级别，整体故障率仍然可以满足要求。
例如，任务A以完全保护（full）执行一次，然后以80%保护（80%）执行一次，最后以40%保护（40%）执行一次。这种组合可以减少任务的执行时间和处理器利用率，同时仍然满足故障率约束。

公式解释

公式表示为： $p_A^{\text{req}} \geq p_A^F \cdot p_A^{80\%} \cdot p_A^{40\%} \geq (p_A^F)^3$

符号解释：

$p_A^{\text{req}}$ ：任务A的要求故障率（例如， $10^{-7}$ 每小时）。
$p_A^F$ ：任务A在完全保护下的实际故障率。
$p_A^{80\%}$ ：任务A在80%保护下的实际故障率。
$p_A^{40\%}$ ：任务A在40%保护下的实际故障率。

示例说明

假设任务A有以下保护级别和执行时间：

完全保护（Full Protection）： $T_F = 100$ ms
80%保护（80% Protection）： $T_{80\%}$ =80ms，实际故障率 $p_A^{80\%} = 2 \times 10^{-4}$
40%保护（40% Protection）： $T_{40\%} = 60$ ms，实际故障率 $p_A^{40\%} = 5 \times 10^{-4}$
组合后的总执行时间为：100+80+60=240 ms。组合后的故障率为： $p_A^F \cdot p_A^{80\%} \cdot p_A^{40\%} = 10^{-4} \cdot 2 \times 10^{-4} \cdot 5 \times 10^{-4} = 10^{-7}$ ，满足要求的故障率。
相比之下，如果任务A连续三次完全保护，执行时间为：3×100=300，故障率为： $(10^{-4})^3 = 10^{-12}$ ，明显过度保护了。

四、任务模型和故障模型 (Task Model and Fault Model)

A. 任务模型 (Task Model)

任务集合 $\Gamma = \{\tau_1, \tau_2, ..., \tau_n\}$ 。每个任务的表示如下：

任务表示：
- 每个任务 τi表示为一个四元组 $C_i, D_i, T_i, p_i^{\text{req}})$ 。
- 其中：
  - Ci：表示任务的不同版本的最坏情况执行时间（WCETs）向量，
  - Di：任务的截止时间（Deadline）。
  - Ti：任务的周期（Period）。
  - $p_i^{\text{req}}$ ：任务 τi的要求故障率（Required Failure Rate）。
多版本编译：
- RTailor将给定的任务 τi 编译成具有不同保护比率的多个版本，即 $\tau_{ij}$ ，其实际故障率为 $p_{F_{ij}}$ 。
- 如果在执行过程中任务 τi发生故障，任务调度器将生成一个包含相同计算的新作业，并重复执行直到成功。
任务重执行：
- 任务 τi的重执行序列定义为： $\tau_i(0), \tau_i(1), ..., \tau_i(N_{\text{re-exec}})$ ，其中 τi(k)是任务 τi的第 k 次重执行， $N_{\text{re-exec}}$ 是任务 τi的重执行总次数。
- 考虑到 τi(k)的最坏情况执行时间 $c_{i_{v_k}}$ ，其中 vk 是在重执行版本序列 $VSEQ_i = (v_0, ..., v_{N_{\text{re-exec}}})$ 中找到的任务版本，RTailor 生成满足任务 τi 故障率约束的最优序列，同时使总执行时间最小。

B. 故障模型 (Fault Model)

RTailor仅考虑处理器中的瞬态故障，也称为软错误。与之前的弹性工作类似，控制流和地址生成单元、缓存和主存储器都被假设为对软错误具有硬化（硬件保护）。RTailor还假设混合关键性系统中的任务调度器也具有某种形式的硬件弹性支持，因此调度器中的故障超出了本文的讨论范围。

瞬态故障的独立性：
- 任务的故障率在其重执行中保持独立。这是因为RTailor仅考虑瞬态故障，而不是永久性故障。
- 由于瞬态故障的特性，后续重执行的故障率与之前执行中的故障无关。
输入完整性保障：
- 即使瞬态故障影响了任务的输出，RTailor保证任务输入的完整性，即任务在执行过程中总是读取正确的输入。
- 保障输入完整性的原因有两点：
  1. 每个任务的输入存储在带有错误纠正码（ECC）的主存储器中。
  2. 输入存储位置与输出存储位置分离，这在所有现代操作系统中都是如此，程序从干净的内存状态开始。

图3展示了RTailor编译器各个阶段的工作流程。以下是对每个阶段的详细解释：

工作流程概述

输入程序：编译流程从输入程序的LLVM中间表示（IR）开始。

循环选择与软错误保护：选择适合软错误保护的循环。

循环转换：根据指定的保护迭代比率进行循环转换。

函数转换：转换被调用的函数以实现保护参数化。

指令复制与幂等处理：生成指令复制和幂等处理的代码。

生成多版本可执行文件：编译输出不同保护比率的多版本可执行文件。

详细解释

1. 循环选择与软错误保护（Loop Selection for Soft Error Protection）

功能：

在这个阶段，编译器首先识别程序中的热循环（即执行频率高的循环），这些循环是参数化软错误弹性的主要目标。

编译器分析每个循环的执行情况，并选择那些最适合进行软错误保护的循环。

2. 循环转换（Loop Transformation）

功能：

编译器使用两种方法之一对被选择的循环进行转换，使得保护迭代比率与输入的保护比率相匹配。

决策块方法：通过在循环中插入决策块来控制哪些迭代受到保护。

循环展开方法：通过展开循环体，将不同的保护级别应用于不同的迭代。

3. 函数转换（Function Transformation）

功能：

对在被参数化循环中调用的函数进行转换，以便这些函数的保护也能够被参数化。

确保被调用函数能够正确处理不同的保护级别。

4. 指令复制与幂等处理（Instruction Duplication for Detection and Idempotence for Recovery）

模块：

指令复制检测（Instruction Duplication for Detection）：$V-D$

幂等处理恢复（Idempotence for Recovery）：$V-E$

功能：

在转换后的循环和函数中，插入指令复制代码以进行错误检测。

使用幂等处理技术，将代码划分为可重新执行的无副作用区域，以实现错误恢复。

5. 生成多版本可执行文件（Generation of Multiple Executable Versions）

功能：

最终，编译器生成多个版本的可执行文件，每个版本具有不同的保护比率。

这些版本将被用于最优重执行版本序列搜索，以找到满足故障率约束的最优执行序列。

五、RTailor概述 (RTailor Overview)

RTailor的目标是为混合关键性实时系统实现细粒度且灵活的软错误弹性方案。通过RTailor的参数化软错误弹性，可以提高任务的调度性并满足所有任务的故障率约束。

RTailor的四个主要功能模块：

循环选择 (Loop Selection)：
- 找到适合弹性参数化的循环。
循环重构 (Loop Restructuring)：
- 转换循环的控制流，使保护迭代比率与输入的保护比率相匹配。
软错误保护代码生成 (Soft Error Protection Code Generation)：
- 为循环体增加检测和恢复软错误的指令。
最优重执行版本序列搜索 (Optimal Re-execution Version Sequence Searching)：
- 找到给定任务 τi 的最优重执行版本序列，使其实际故障率通过重执行满足故障率约束，并使总执行时间最小。

编译器工作流

图3展示了RTailor的编译工作流：

输入程序：
- 从LLVM中间表示（IR）开始，这是由如Clang等语言前端为C/C++生成的。
循环选择与重构：
- RTailor的编译器选择候选循环进行参数化软错误弹性，并转换它们的控制流，使保护迭代比率与总迭代次数匹配。
函数转换：
- 转换在参数化循环中调用的函数，以使它们的保护也可以参数化。
指令复制与幂等处理：
- 在转换后的循环和函数上执行指令复制和幂等处理，以检测和纠正软错误。
多版本编译：
- RTailor将任务 τi编译成具有不同保护比率的多个版本，并将它们与最坏情况执行时间、实际故障率和要求故障率一起输入到最优重执行版本序列搜索算法中，以找到最优重执行序列。

六、 RTailor编译器实现

A. 循环选择用于参数化软错误保护

RTailor通过选择程序（任务）执行期间的一部分代码来实现参数化的软错误弹性。也就是说，RTailor选择输入程序中的某些代码，并决定它们是否应该受到保护，并根据需要的弹性级别确定适当的保护程度。

候选代码选择的两个重要属性：

执行时间占优：程序在这些代码上的大部分执行时间，否则参数化对整体弹性和性能的影响可以忽略不计。
高执行次数：代码在程序执行期间被执行足够多的次数，这样RTailor可以以细粒度方式实现参数化。

表1显示了在NPB基准测试套件中的各个程序（如BT, CG, EP, FT, IS, LU, MG, SP）的循环执行时间占程序总执行时间的比例。对于这些程序，99%的总执行时间都在循环中度过，这表明大部分计算资源消耗在循环执行上。这个特性使得这些程序非常适合进行参数化的软错误弹性保护。

循环作为候选代码：

很多实时系统应用程序都是以循环为主的。
表1显示了在NPB基准测试应用程序中，99%的总执行时间都花费在循环上。

嵌套循环的处理：

不同层级的嵌套循环具有不同的执行属性。
RTailor提出了三种策略来选择嵌套循环中的理想循环层级：
1. 最外层策略：优先考虑执行时间占优的最外层循环。
2. 最内层策略：优先考虑高执行次数的最内层循环。
3. 基于性能剖析的选择策略：结合以上两种策略的优点。

(a) 嵌套循环

显示了嵌套循环的层次结构，最外层是Loop 1，内部嵌套了Loop 1.1和Loop 1.2，Loop 1.2内部又嵌套了Loop 1.2.1和Loop 1.2.2。

(b) 循环结构树

展示了对应嵌套循环的循环结构树。树的节点表示不同的循环，边上的数字表示循环的回边计数（即循环执行的次数）。
通过遍历结构树，RTailor可以选择执行时间占优的外层循环或迭代次数高的内层循环，具体选择基于回边计数是否超过一定阈值（如100）。

通过性能剖析，记录循环的回边计数（如图4b所示），构建循环结构树，并选择回边计数超过阈值的循环节点作为目标循环层级。

B. 准备循环用于参数化保护

(a) 原始循环

描绘了一个简单的循环结构，包括循环头、循环体和循环退出块。

(b) 决策块形成

在循环头之后插入一个决策逻辑块，用于决定即将执行的循环迭代是否需要保护。
决策逻辑通过生成一个随机数并与阈值比较来决定执行受保护的代码还是不受保护的代码。

(c) 推测性循环展开

通过展开循环体，使得部分展开的循环体受到保护，而另一些不受保护。
这种方法消除了决策逻辑的需要，从而减少了运行时开销。

生成一个0到100之间的随机数R。
根据保护迭代比率N初始化阈值为N×100。
如果随机数R小于阈值，则分支到受保护的代码；否则，分支到不受保护的代码。

两种循环转换方法：

决策块形成（Decision Block Formation）
- 插入决策逻辑块决定即将执行的循环迭代是否需要保护。
- 如图5b所示，决策逻辑块通过生成随机数并与阈值比较，决定执行受保护的代码还是不受保护的代码。
- 算法1描述了决策逻辑的实现。
推测性循环展开（Speculative Loop Unrolling）
- 展开循环体，部分循环体受到保护，部分不受保护。
- 如图5c所示，根据用户定义的保护迭代比率选择性地保护展开的循环体。

决策块方法的问题：

决策逻辑块会引入高运行时开销，主要因为：
1. 随机数生成器会显著降低处理器核心中的分支预测器的效果，导致频繁的误预测和昂贵的流水线刷新。
2. 随机数生成本身需要时间，决策块会占据小循环的大部分执行时间。

循环展开方法的优势：

消除了决策逻辑的需要，减少了动态指令的引入，降低了性能开销。
表2显示了在不同的保护迭代比率下，决策块方法相对于循环展开方法的平均减速比。

显示了在不同的保护迭代比率（20%, 40%, 60%, 80%）下，决策块方法相对于循环展开方法的平均减速比。
决策块方法的运行时开销较高，而循环展开方法则具有较小的性能开销。

C. 函数的参数化保护准备

(a) 原始代码

显示了未经过保护的函数调用结构。

(b) 嵌套函数内联

在保护的调用点内联函数体，递归地将所有函数内联到保护的调用点中。

(c) 函数克隆与名称修饰

克隆保护调用点中的函数，并重命名这些克隆函数以确保它们只被保护的调用点调用。
修改保护代码中的调用指令以调用重命名后的克隆函数。

函数调用点的保护问题：

函数是否受到保护取决于其调用点是否受到保护，这会导致冲突情况。
RTailor生成函数的受保护版本和不受保护版本，并根据调用点的位置选择调用哪个版本。

两种技术：

嵌套函数内联（Nested Function Inlining）
- 递归地内联保护调用点中的所有函数，如图6b所示。
函数克隆与名称修饰（Function Cloning and Name Mangling）
- 克隆保护调用点中的函数，并重命名这些克隆函数，使它们只被保护的调用点调用，如图6c所示。

D. 错误检测的指令复制

(a) 原始汇编代码

显示了未经过处理的原始汇编代码。

(b) DMR后的代码

通过指令复制实现错误检测，在每个同步点插入错误检查指令。
比较原始指令和复制指令的输出值，以检测软错误。

(c) 幂等处理后的代码

将程序划分为幂等区域，每个区域内的内存写后读（WAR）依赖被打破。
插入检查点存储指令以保存每个区域的输入寄存器值。
当检测到错误时，重定向程序控制到恢复代码块，从检查点恢复输入寄存器值，然后重新执行中断的区域。

指令复制用于错误检测：

RTailor通过指令复制检测软错误，插入错误检查指令比较原始指令和复制指令的输出值。
如图7b所示，插入错误检查指令以检测潜在的软错误，任何不匹配都指示错误的发生。

E. 幂等处理用于错误恢复

幂等区域划分：

RTailor将程序划分为一系列幂等区域，每个区域内没有内存写后读（WAR）依赖。
插入检查点存储指令以保存每个区域的输入寄存器值，确保重新执行时读取正确的输入值。

错误恢复协议：

当检测到错误时，程序首先被中断，然后重定向到编译器生成的恢复代码块。
恢复代码块从检查点存储中重新加载输入寄存器值，然后跳回到中断区域的开始重新执行，以进行错误恢复。

七、搜索最优的重执行版本序列

在本节中，RTailor描述了如何找到最优的任务重执行版本序列，以最小化总执行时间，同时满足故障率约束。与之前的工作不同，RTailor通过参数化的软错误保护大大减少了总执行时间，提高了任务的整体可调度性。

问题定义: 给定一个任务τi及其不同版本的集合V，RTailor需要找到最优的重执行版本序列VSEQi，使得实际故障率乘积满足要求的故障率约束，并且总执行时间最小化。

具体步骤:

将每个任务版本的WCET量化（四舍五入到两位小数）。
将任务的实际故障率和要求的故障率进行负对数转换，以便将故障率乘积转换为对数和。
根据这些转换，将问题转换为一个无界0-1背包问题。

背包问题变量映射：

表格展示了背包问题和RTailor最优重执行版本序列问题之间的变量映射：

集合的物品：VSEQi (任务τi的重执行版本序列)
物品j：τij（任务i的版本j）
物品的重量：cij（τij的WCET）
总重量：∑civk（重执行版本序列的总WCET）
物品的价值：-log10 pFij（负对数转换后的实际故障率）
总价值：-∑log10 pFivk（总的负对数转换后的实际故障率）

算法2：找到最优重执行版本序列

此算法使用动态规划解决无界0-1背包问题，以找到最优的重执行版本序列。关键步骤包括：

初始化背包的最大重量和价值数组。
增加背包的最大重量W，直到满足故障率约束。
通过遍历版本集合，构建价值最高且重量不超过W的物品集合。
回溯找到最优的重执行版本序列。

初始化：
- 最大重量W初始化为0。
- 价值数组Av初始化为空，用于存储每个重量下的最大价值。
- 回溯数组Ah初始化为空，用于记录每个重量下选择的物品。
增加背包的最大重量：
- 每次增加背包的最大重量W，并更新价值数组和回溯数组。
- 对于每个版本j，计算重量x（当前重量减去版本重量）和价值y（当前价值加上版本价值）。
- 如果y大于当前重量下的最大价值，则更新价值数组和回溯数组。
构建最优重执行版本序列：
- 初始化最优版本序列VSEQi为空。
- 根据回溯数组Ah，从最后一个重量开始回溯，找到最优的重执行版本序列。

示例解释：

对于每个任务版本j，算法会根据其WCET和实际故障率更新价值数组和回溯数组。通过动态增加背包重量，算法寻找最小总WCET的重执行版本序列。这个过程确保任务在满足故障率约束的前提下，以最小的执行时间被重执行。

八、其他相关工作

在这一部分，文章讨论了与RTailor相关的其他研究工作，特别是那些关注于能量感知的可靠性管理的实时系统方案。这些方案与RTailor类似，为实时任务提供了基于应用需求的定制可靠性。以下是这部分内容的详细解释：

能量感知的可靠性管理

先前的方案研究了如何在实时系统中进行能量感知的可靠性管理。例如，任务复制（task replication）技术被用来应对故障率约束的任务。这些方案会持续生成任务的副本，直到所有副本执行失败的概率低于要求的故障率。然而，这些方案往往会导致任务的过度保护，因为它们缺乏参数化的软错误弹性（如图1所示）。具体而言，这些方案利用过度保护作为安全保障，以实现激进的动态电压和频率调节（DVFS），在能效和可靠性之间进行权衡。

RTailor的不同之处

与上述方案不同，RTailor通过参数化软错误弹性从一开始就解决了过度保护的问题。对于需要重新执行以降低故障率的任务，RTailor组合了参数化的任务版本序列，这些版本具有不同的保护比例。结果表明，RTailor的过度保护比现有方案小得多。此外，RTailor可以与这些方案的DVFS技术协同工作，进一步减少过度保护并提高能效，而不会违反实时任务的故障率约束。这种方法特别适用于能量收集系统，这也是RTailor未来研究的一个方向。

九、结论

在这一部分，文章总结了RTailor的主要贡献和实验结果：

RTailor的贡献

RTailor提供了一种灵活且细粒度的软错误弹性参数化方法，适用于混合关键性的实时系统。为了满足特定的可靠性需求，RTailor的编译器会转换每个任务的循环，使其迭代保护频率与需求相匹配。实验结果表明，RTailor的参数化软错误弹性可以显著提高实时任务的可调度性，相比于最先进的工作，提升幅度可达21%。

详细解释

能量感知的可靠性管理

在能量感知的实时系统中，任务复制技术是实现可靠性的常用方法。任务复制技术通过生成多个任务副本，确保即使某些副本执行失败，整个系统的故障率仍然在可接受范围内。然而，这种方法会导致过度保护，因为它们缺乏对软错误弹性的精细控制。

动态电压和频率调节（DVFS）

DVFS是一种通过调整处理器电压和频率来平衡能效和可靠性的技术。在降低电压和频率的同时，系统的能耗会降低，但这也可能增加软错误的发生概率。因此，现有方案往往利用过度保护来应对这种权衡。然而，RTailor通过参数化软错误弹性，从源头上减少了过度保护的必要性。

RTailor的参数化方法

RTailor通过细粒度控制任务的软错误保护水平，优化了任务的重执行版本序列。这种方法不仅减少了过度保护，还提高了任务的整体可调度性。具体而言，RTailor利用动态编程解决了一个无界0-1背包问题，以找到最优的重执行版本序列，使总执行时间最小化，同时满足故障率约束。

D了一天bug忘了编译

关注

46
点赞
踩
13

收藏

觉得还不错? 一键收藏
打赏
1
评论
操作系统论文导读（十八）：RTailor: Parameterizing Soft Error Resilience for Mixed-Criticality Real-Time Systems

软错误：软错误是任务执行期间因高能粒子撞击引起的错误，如宇宙射线。这些错误会改变寄存器和内存单元中的数据，而不会造成物理硬件损坏。软错误可能导致系统崩溃、挂起或数据损坏。重要性：在关键任务嵌入式系统（如无人机）中，软错误可能导致严重后果。例如，飞行控制内核中的软错误可能导致发送错误信号给执行器，从而导致无人机坠毁。现有问题：传统的软错误弹性方案（如指令冗余）在任务执行期间整体开启或关闭，无法细粒度地控制弹性级别。这会导致不必要的性能开销，从而影响任务的调度性。参数化执行序列。
复制链接

扫一扫