缓存分区可提高安全关键型多核应用程序的CPU利用率

缓存分区减少了关键任务的最坏情况下的执行时间，从而提高了 CPU 利用率，尤其是对于多核应用程序。

多核处理器 （MCP） 的可认证、安全关键型软件应用程序的开发人员面临的最大挑战之一是管理对共享资源（如缓存）的访问。MCP 显著增加缓存争用，导致最坏情况执行时间 （WCET） 超过平均案例执行时间 （ACET） 100% 或更多。由于安全关键型开发人员必须为 WCET 制定预算，因此平均分配的任务（关键和非关键）的时间超过了所需的时间，从而导致 CPU 利用率显著降低。解决此问题的一种方法是利用支持缓存分区的 RTOS，它使开发人员能够以减轻争用和减少 WCET 的方式绑定和控制干扰模式，从而在不影响安全关键性的情况下最大化可用 CPU 带宽。

缓存争用

在简单的双核处理器配置（图 1）中，每个内核都有自己的 CPU 和 L1 缓存。两个内核共享一个二级缓存。（请注意，未显示共享内存和可选 L3。

图1：双核配置，无需缓存分区

在此配置中，在核心 0 上执行的应用程序与在核心 1 上执行的应用程序竞争整个二级缓存。（请注意，同一内核上的应用程序也会相互竞争 L2;缓存分区也适用于这种情况。如果核心 0 上的应用程序 A 使用的数据映射到与核心 1 上的应用程序 B 相同的缓存行，则会发生冲突。

例如，假设 A 的数据驻留在 L2 中;对该数据的任何访问都将花费很少的处理器周期。但假设 B 访问的数据恰好映射到与 A 的数据相同的 L2 缓存行。此时，必须从 L2 中逐出 A 的数据（包括对 RAM 的潜在“写回”），并且必须将 B 的数据从 RAM 中引入缓存。处理此碰撞所需的时间通常由 B 收取。然后，假设 A 再次访问其数据。由于该数据不再位于 L2 中（B 的数据在其位置），因此必须从 L2 中逐出 B 的数据（包括潜在的“写回”到 RAM），并且 A 的数据必须从 RAM 中恢复到缓存中。处理此碰撞所需的时间通常由 A 收取。

大多数时候，A和B很少会遇到这样的碰撞。在这些情况下，它们各自的执行时间可以被视为“平均情况”（ACET）。但是，有时，它们的数据访问会以高频率发生冲突。在这些情况下，它们各自的执行时间必须被视为“最坏情况”（WCET）。

在开发可认证的安全关键型软件时，必须为最坏情况的行为预算应用程序的执行时间。此类软件必须有足够的时间预算才能在每次执行时完成其预期功能，以免导致不安全的故障情况。安全关键型 RTOS 必须强制实施时间分区，以便每个应用程序都有固定的 CPU 时间预算来执行。

由于多个内核上的多个应用程序可能会产生对 L2 缓存的争用，因此 MCP 上的 WCET 通常比 ACET 高得多。由于可认证的安全关键型应用程序必须有时间预算来容纳其 WCET，这种情况会导致大量预算但未使用的时间，从而导致 CPU 利用率显著下降。

缓存分区

缓存分区通过减少 WCET 来提高 CPU 利用率，从而减少必须预算以容纳 WCET 的时间量。同样，在简单的双核处理器配置（图 2）中，每个内核都有自己的 CPU 和 L1 缓存，并且两个内核共享一个 L2 缓存。

图2：具有缓存分区的双核配置

在此配置中，RTOS 对 L2 缓存进行分区，以便每个内核都有自己的 L2 段，这意味着内核 0 上的应用程序使用的数据将仅缓存在内核 0 的 L2 分区中。同样，核心 1 上的应用程序使用的数据将仅缓存在核心 1 的 L2 分区中。这种分区消除了不同内核上的应用程序通过 L2 冲突相互干扰的可能性。如果没有这种干扰，应用程序 WCET 和 ACET 之间的增量通常比没有缓存分区的情况要低得多。通过限制和控制这些干扰模式，缓存分区使应用程序执行时间更具确定性，并使开发人员能够更严格地预算执行时间，从而保持较高的处理器利用率。

测试环境和应用程序

为了演示缓存分区的优势，DDC-I 使用 Deos（其可认证、安全关键、时间和空间分区的 RTOS）来运行一套四个内存密集型测试应用程序，所有这些应用程序都具有一系列数据/代码大小、顺序和随机访问策略以及各种工作集大小：

只读

只写

复制

代码执行

测试是在具有 32 KB L1 数据缓存、24 KB L1 指令缓存和 512 KB 统一 L2 缓存的 1.6 GHz 凌动处理器 （x86） 上进行的。请注意，虽然这些测试使用了单核 x86 处理器，但 Deos 的缓存分区功能同样适用于在同一内核上执行的应用程序（这些应用程序也竞争 L2）。此外，它不依赖于 x86 处理器所特有的任何功能，并且同样适用于其他处理器类型（如 ARM 或 PowerPC）。

测试是在有和没有“缓存垃圾箱”应用程序的情况下运行的，该应用程序从L2中逐出测试应用程序数据/代码，并使用自己的数据/代码“脏”L2。实际上，从测试应用程序的角度来看，缓存垃圾程序将 L2 置于最坏情况状态。也就是说，缓存垃圾箱模拟真实场景，其中不同的应用程序同时运行并争用共享的 L2 缓存。

每个测试应用程序在三种情况下执行。在场景 1 中，在没有缓存分区或缓存垃圾的情况下执行，测试应用程序将竞争整个 512 KB 二级缓存以及 RTOS 内核和各种调试工具。此测试建立基线平均性能，其中每个测试都以“平均”数量的 L2 争用执行。

在不使用缓存分区的场景 2 中，测试应用程序与 RTOS 内核、场景 1 中使用的同一组调试工具以及恶意缓存垃圾程序应用程序竞争整个 512 KB 二级缓存。此测试建立基线最坏情况性能，其中每个测试在来自其他应用程序（主要是缓存垃圾程序）的最坏情况下执行 L2 干扰。

在使用缓存分区和缓存垃圾的场景 3 中，将创建三个 L2 分区：

分配给测试应用程序的 256 KB 分区

分配给 RTOS 内核的 64 KB 分区以及方案 1 和方案 2 中使用的同一组调试工具

分配给恶意缓存垃圾程序应用程序的 192 KB 分区。

此方案建立了优化的最坏情况性能，其中每个测试在其自己的 L2 分区内执行，不受其他应用程序（包括缓存垃圾程序）的干扰。

缓存分区结果、优势

图 3 显示了只读测试应用程序的结果。

图3：缓存分区对只读测试的影响

例如，在没有缓存分区和缓存垃圾的情况下（方案 1，ACET），只读测试在工作集大小为 512 KB 的情况下，每次执行的平均时间为 105 微秒。在方案 2（没有分区的 WCET，添加了缓存垃圾箱）中，对于相同的 512 KB 工作集，测试平均每次执行 400 微秒，增加了 280%。添加缓存分区（方案 3，带缓存垃圾的 WCET）时，平均执行时间降至 117 微秒，仅比 ACET 高 11%。

这些结果证明了缓存分区对于每个周期执行大量读取的应用程序的有效性。尽管由于量级差异，此处很难辨别，但当应用程序的工作集大小适合其使用的缓存分区（在本例中为 256 KB）时，对边界 WCET 的影响更为明显。由于缓存的性质，此结果是预期的。也就是说，嵌入式实时应用程序的工作集大小往往相对较小，因此我们预计缓存分区将使大多数应用程序受益。

只写测试的结果与只读测试相似，但对于较小的工作集更明显。对于较大的工作集，结果显示具有和不具有缓存分区的 WCET 之间的差异相对较小。

复制测试的结果与只读测试相似，但对于较小的工作集更明显。对于较大的工作集，结果不那么显着，但仍然显示出具有缓存分区的 WCET 的显着改进（大约 2 倍）。

代码执行测试的结果与只读测试类似，但稍微不那么引人注目。

请注意，在同一缓存分区中执行的应用程序可能会相互干扰。但是，与在具有共享缓存的不同内核上执行的应用程序之间可能发生的不可预测的干扰模式相比，此类干扰通常更容易分析和绑定。在这些情况下，如果干扰不可预测，则可以将应用程序映射到单独的缓存分区。

基准测试结果清楚地表明，缓存分区提供了一种有效的方法来绑定和控制 MCP 上共享缓存中的干扰模式。特别是，在对缓存进行分区时，可以更严格地绑定和控制 WCET。这允许应用程序开发人员设置相对紧凑但安全的执行时间预算，从而最大限度地提高 MCP 利用率。

当然，不同的应用和硬件配置的结果会有所不同，并且需要额外的RTOS功能才能成功认证基于安全关键型MCP的系统。无论如何，这些结果代表了在使用MCP托管可认证的安全关键应用程序的目标方面的重大进步。

审核编辑：郭婷