一、概述

cachespeed 是一款命令行基准测试工具，旨在精确测量 openvela 系统中缓存 (Cache) 操作的性能。它通过对指令缓存 (Instruction Cache, I-Cache) 和数据缓存 (Data Cache, D-Cache) 执行 invalidate (失效)、flush (刷回) 与 clean (写回) 操作，来量化其运行耗时。为提供全面的性能数据，该工具覆盖了内存地址对齐和非对齐两种测试场景。

技术术语解析

• clean (写回)：将缓存中被修改过（“脏”）的数据写回主内存，但数据仍保留在缓存中。
• invalidate (失效)：将缓存中的数据标记为无效，但不写回主内存。下次访问该数据时，CPU 会强制从主内存重新加载。
• flush (刷回/冲刷)：通常是 clean 和 invalidate 操作的组合。它先将脏数据写回主内存，然后将对应的缓存行置为无效。

目标读者

本文档面向需要在 openvela 实时操作系统 (RTOS) 上进行性能分析和优化的开发者，包括：

• 系统性能工程师：负责评估和调优系统整体性能。
• 嵌入式内核开发者：负责开发或维护底层内存管理和处理器架构相关代码。
• 板级支持包 (BSP) 工程师：负责将 openvela 移植到新硬件平台并验证其性能。

二、前置条件

该工具依赖 up_perf_gettime() 函数进行高精度计时。在运行测试前，您必须确保系统的性能计数器已正确配置。

对于基于 ARMv8-M 架构的平台，需要通过设置以下寄存器来使能周期计数器 (Cycle Counter)。通常，您可以在调试器或系统启动脚本中执行这些命令。

// 示例，请根据目标芯片确认
mw 0xe000edfc=0x01100000
mw 0xe0001000=0x48000001

三、编译配置

为确保基准测试结果的准确性，请在构建配置文件中应用以下配置。这些设置可以最大限度地减少可能干扰测试的系统开销。

# --- 性能与优化 ---
DEBUG_CUSTOMOPT=y          # 启用自定义优化选项
DEBUG_OPTLEVEL=-O3         # 设置编译器优化等级为 -O3，确保代码以最高效率运行

# --- 关闭监控与安全检查 ---
CONFIG_SCHED_INSTRUMENTATION=n # 关闭调度器测量
CONFIG_SCHED_IRQMONITOR=n      # 关闭中断监控
CONFIG_SCHED_CRITMONITOR=n     # 关闭临界区监控
CONFIG_STACK_CANARIES=n        # 关闭栈保护。此项对性能影响极大，尤其在短函数调用场景，
                               # 可能导致高达 3 倍的性能差距
CONFIG_WATCHDOG=n              # 关闭看门狗，防止在长时间测试中触发系统复位

# --- 使能测试工具 ---
CONFIG_BENCHMARK_CACHESPEED=y  # 编译 cachespeed 工具

四、运行测试

该工具的源代码位于 apps/benchmarks/cachespeed 目录下。在系统 shell 中执行 cachespeed 命令即可运行测试。

示例输出

cachespeed
CACHE Speed: address src: 38506ec0
** dcache invalidate [rate, avg, cost] in nanoseconds(bytes/nesc) align **
64 Bytes: 0.045714, 1400, 14000
128 Bytes: 0.116364, 1100, 11000
192 Bytes: 0.128000, 1500, 15000
256 Bytes: 0.182857, 1400, 14000
320 Bytes: 0.213333, 1500, 15000
384 Bytes: 0.256000, 1500, 15000
448 Bytes: 0.320000, 1400, 14000
...

五、结果解读

测试流程通常从单个缓存行大小开始，逐步增大数据块尺寸，直到接近或超过缓存容量。分析时以 avg 为主；rate 与 cost 提供辅助视角，但容易受样本大小与测量方法影响。

输出结果各列含义如下：

指标	单位	描述
rate	字节/纳秒	处理速率，计算公式为 (测试数据大小) / avg。
avg	纳秒	(关键指标) 执行单次缓存操作的平均耗时。
cost	纳秒	完成指定数据大小所有迭代测试的总耗时。

六、工作原理解析

理解缓存操作的底层机制，有助于您正确解读性能数据。

1、Invalidate (失效)

• 现象：invalidate 操作的速率 (rate) 通常会随着测试数据量的增大而提高。
• 原因解析：invalidate 操作的核心开销（例如，CPU 查找缓存标签并将其置为无效状态）相对固定，与要失效的数据块大小关系不大。当您用这部分相对固定的时间 (avg) 处理更大数据块 (size) 时，计算出的平均速率 (rate = size / avg) 自然会随之上升。

2、Clean (写回) 与 Flush (刷回)

• 现象：当测试数据的大小超过物理 D-Cache 的总容量时，clean 和 flush 操作的平均耗时 (avg) 会趋于一个稳定值。
• 原因解析：clean 和 flush 操作需要将脏数据（被修改过的数据）从缓存写回至主内存。一旦测试数据量大到无法完全装入缓存，性能瓶颈就从缓存内部的执行速度转移到了速度慢得多的内存总线带宽上。由于总线带宽是固定的，系统向主内存写回数据的速度也趋于恒定，因此单次操作的平均耗时 (avg) 不再随数据量的增加而显著变化。

结论：分析 cachespeed 输出时，请把重点放在 avg 上，并结合目标平台的缓存大小、缓存行尺寸与内存带宽来做归因分析。

七、延伸阅读

• ARM 架构参考手册 (ARMv8-M)

  • 查阅此手册可获取 DWT、缓存控制器等底层硬件模块的权威技术规范。