TechBlog

Appearance

RK3588 板端性能 A/B：怎样证明一条新流水线真的更省资源 ​

把图像链路从 CPU copy 改成 DMA-BUF，把鱼眼矫正迁到 GPU，代码上看起来更高效，但性能结论不能来自架构图。板端 A/B 要回答三个问题：运行的是不是目标版本、业务功能是否等价、资源差异是否真的来自改动。

为什么推荐 A1 → B → A2 ​

直接先测旧版 B、再测新版 A，容易把温度、缓存、后台任务和测试顺序混进结果。更稳的顺序是：

text
A1（新版） → B（基线） → A2（新版复测）

如果 A1 与 A2 接近，而 B 稳定地落在另一水平，结果更可信。每轮都应包含固定预热和固定采样窗口，例如：

  • 预热 60 秒，让服务进入稳态；
  • 采样 120 秒或更长；
  • 三轮使用相同输入、频率和算法配置。

1. 先证明版本身份 ​

切换安装包或 release 后，旧进程可能仍持有相机设备。服务看似重启成功，实际采样的却是混合版本。

每轮开始前至少确认：

bash
systemctl show <service> -p MainPID
readlink -f /proc/<pid>/exe

同时记录构建 commit、安装包 hash 与实际 executable 路径。任何一个参与主链的进程不是目标 release，本轮数据都应作废。

2. 功能等价是性能测试的前置门禁 ​

CPU 降低可能只是某个模块没有工作。采样前要确认：

  • 相机 bundle 频率；
  • 左右图或 atlas 频率；
  • IMU 输入频率；
  • VINS odometry 频率；
  • NPU 推理或编码输出是否持续；
  • health/watchdog 是否没有隐性重启。

只有功能输出一致，资源对比才有意义。

3. CPU 不能只看目标进程 ​

图像优化经常把成本从一个进程转移到内核线程、softirq、GPU、RGA 或另一个服务。建议同时记录：

  • 整机 CPU；
  • 主链各进程 CPU/RSS；
  • NET_RX 等 softirq；
  • RGA/NPU/GPU；
  • Shmem、page cache、slab 与普通可用内存。

如果必须排除某个非业务服务，应在测试方案里提前声明；采样工具自身的 CPU 也要关闭或单列扣除。

4. GPU 必须使用 busy/idle 增量 ​

某些监控工具展示的是累计值或瞬时点，不能证明采样窗口里 GPU 真正工作。更可靠的做法是读取 Mali 的 busy_time 与 idle_time，用窗口首尾差值计算：

text
gpu_util = Δbusy / (Δbusy + Δidle)

GPU 占用低也不等于 kernel 没执行。如果每帧 kernel 只有几毫秒、帧率又不高，平均利用率本来就可能很低。应结合 kernel duration、调用样本数和业务频率一起解释。

5. 内存要拆成多层 ​

至少分开观察：

  • 进程 RSS；
  • 共享内存 Shmem；
  • DMA-BUF owner 与 size；
  • page cache；
  • slab；
  • NPU/ISP/编码器的内部池。

只看 free 或 MemAvailable，很难判断优化到底减少了进程拷贝、共享内存，还是仅仅改变了缓存状态。

6. 两分钟稳定不等于没有泄漏 ​

短窗口可以用于比较稳态资源，但不能作为 leak gate。内存泄漏验证至少要补一小时以上的 steady-state，并记录：

  • RSS slope；
  • Shmem slope；
  • DMA-BUF in-flight 数量；
  • slab/allocator 变化；
  • 周期性重连或重启后的回落情况。

一份可复用的报告结构 ​

  1. 测试目标与假设；
  2. A/B 版本身份；
  3. 板卡、内核、配置与输入负载；
  4. 预热/采样窗口；
  5. 功能门禁结果；
  6. CPU、内存、GPU、RGA、NPU、softirq；
  7. A1/B/A2 原始值与聚合；
  8. 已证明的结论；
  9. 尚未证明的边界，如长期泄漏与 buffer 安全。

好的性能报告不仅给出“快了多少”，还会清楚说明运行了什么、测了什么、没有证明什么。