📚 课程目录第4章 CPU性能诊断与调优

4. CPU性能诊断与调优

Jetson 平台的 CPU 性能问题往往不是“算力不够”这么简单。以 Jetson Orin NX 16GB 为例，它包含 6 个 Cortex-A78AE 大核（最高约 1.98GHz）和 2 个 Cortex-A55AE 小核（最高约 1.37GHz），大小核共享 L3 缓存，并受同一套 DVFS（动态电压频率调节）与热管理策略约束。当应用出现延迟抖动、吞吐下降或某线程长期跑不满时，真正的原因可能是频率被限制、任务被调度到小核、关键线程被其他负载抢占，或者根本卡在内存带宽与 I/O 上。因此诊断顺序应当是：先看频率与负载分布，再看调度与亲和性，最后判断瓶颈究竟在 CPU 计算、内存还是外设。

一、CPU 频率调节：先确认“跑在什么频率上”

Jetson 的 CPU 频率由 cpufreq 子系统管理，常见 governor 有 schedutil、ondemand、performance、powersave。默认 schedutil 会根据调度器负载快速升频，但在短时突发负载下仍可能出现升频滞后。查看当前状态：

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

若要做确定性性能测试，可临时锁定频率（示例，需 root）：

sudo su
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# 对每个 online CPU 重复，或使用 cpufreq-set
for c in /sys/devices/system/cpu/cpu[0-7]; do
  echo performance > $c/cpufreq/scaling_governor
done

注意：锁定 performance 会提高功耗与温度，长时间运行可能触发热降频。判断是否降频，可对比 scaling_cur_freq 与 cpuinfo_max_freq，并观察 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state 中各频率的驻留时间。如果高频档位驻留时间很短，说明负载不足或热限制在起作用。

二、核心隔离与调度策略：把关键线程放到“干净”的核上

Jetson 上常见的干扰源包括内核线程、中断处理、其他容器或后台服务。核心隔离的目标是让实时或高优先级线程独占某些 CPU，减少上下文切换与缓存污染。Linux 提供两种主要手段：isolcpus 内核参数与 cpuset cgroup。

在 /boot/extlinux/extlinux.conf 的 APPEND 行加入 isolcpus=4-7，可将 CPU4~CPU7 从通用调度器中隔离出来，之后用 taskset 或 sched_setaffinity 把关键线程绑定到这些核：

taskset -c 4-7 ./my_realtime_app
# 查看线程当前亲和性
taskset -cp $(pgrep -f my_realtime_app)

调度策略方面，普通线程使用 SCHED_OTHER（CFS）；对延迟敏感的线程可设为 SCHED_FIFO 或 SCHED_RR，但必须谨慎，因为实时线程优先级高于所有普通线程，一旦死循环会拖死系统。示例：

chrt -f 80 ./my_realtime_app   # SCHED_FIFO, 优先级 80
chrt -p $(pgrep -f my_realtime_app)

更稳妥的做法是配合 cpuset 把非关键任务限制在小核或部分大核上，例如把后台服务绑定到 CPU0~CPU3，把推理/控制线程绑定到 CPU4~CPU7，从而形成物理隔离。

三、负载分析与瓶颈定位：用数据说话

常用工具包括 top、htop、mpstat -P ALL 1、pidstat -t -p <pid> 1、perf top 与 tegrastats。判断瓶颈时重点看四类信号：

单核打满、其他核空闲：典型串行瓶颈，考虑多线程拆分或把线程迁移到空闲核。
所有核都高但吞吐不涨：可能受内存带宽、L3 缓存或 I/O 限制，需结合 perf stat 看 cache-miss 与 stalled cycles。
CPU 使用率不高但延迟大：检查是否被调度延迟、锁竞争或中断打断，可用 perf sched latency 观察。
频率频繁波动：结合 time_in_state 与温度，判断是负载驱动还是热降频。

下面这张图把“频率—亲和性—调度策略—负载观测—瓶颈判断”串成一条诊断链，便于在实际排查时按路径定位。

四、一个可复现的排查示例

假设某视觉推理程序在 Orin NX 上单帧延迟从 18ms 波动到 45ms。按上述路径排查：

运行 mpstat -P ALL 1，发现 CPU0 长期 95% 以上，CPU4~CPU7 利用率不足 20%。
用 pidstat -t -p <pid> 1 看到主线程与推理线程都落在 CPU0~CPU3，且频繁迁移。
检查 governor 为 schedutil，time_in_state 显示高频档位驻留比例偏低。
将推理线程用 taskset -c 4-7 绑定，并把 governor 临时设为 performance 复测。
复测后单帧延迟稳定在 20ms 左右，CPU4~CPU7 利用率上升，CPU0 压力下降，说明原瓶颈是调度分布不均与升频滞后，而非算力不足。

调优后应恢复合理的 governor 与亲和性设置，避免长期锁定 performance 导致过热降频。建议把关键配置写入 systemd 服务或启动脚本，保证重启后一致。

使用 SCHED_FIFO 时务必设置合理的优先级与运行时间上限，并保留至少一个 CPU 给系统线程，否则可能出现系统无响应。

总结来看，Jetson CPU 调优的核心不是盲目提高频率，而是让正确的线程跑在正确的核上、以正确的频率和调度策略运行，并用可观测数据验证每一步改动。频率、隔离、调度、负载四者相互影响，只有形成闭环验证，才能真正定位并消除瓶颈。