CPUIdle 联合调优实践

本文包含了调优服务的完整 Shell 脚本、Systemd 服务配置、UCLAMP C++ 核心代码以及详细的命令行排查过程和日志监测输出：

在基于嵌入式 SoC 平台（如 RK3588）的边缘 AI 项目落地中，神经网络推理时延的稳定性往往是确保整个实时流管线（V4L2 采集 -> NPU 检测 -> MPP 视频编码）吞吐率的关键。

在实际项目部署中，我们遇到了推理时延波动（Jitter）以及在纯净测试环境下时延反常增大的问题。本文记录了我们对该现象的排查定位过程，深度剖析了 CPU 动态调频器（Governor）、DDR 频宽总线带宽以及 CPUIdle C-State 睡眠切换对推理关键路径的影响，并提供了全链路定频与应用生命周期绑定的工程化调优方案。

一、背景与反常现象分析

为了给我们的边缘检测网关 AlertGateway 的 YOLOv8s 目标检测模块建立一个性能基准，我们首先在开发板（Firefly RK3588S，板载 Linux 6.1.118 内核，RKNN Driver 2.3.0）上运行官方 rknn_model_zoo 的 C++ 测速 Demo。但在测试中发现了一个反直觉的现象：

官方 Demo（纯净推理，无背景干扰）：循环 30 次推理中，rknn_run 纯 NPU 推理耗时在 79ms ~ 128ms 之间剧烈抖动，平均时延高达 97ms。
AlertGateway 业务管线（多线程并发）：在有摄像头采集与 H.264 编码等背景负载下，推理线程的 rknn_run 耗时反而稳定在 ~48ms 左右。

1. 现场诊断：CPU 状态采样

在运行官方 Demo 期间，我们使用以下命令行，每隔 0.3s 采样一次板端 8 个 CPU 核心的实时运行频率与 Governor 状态：

watch -n 0.3 "echo '=== CPU Governors ===' && cat /sys/devices/system/cpu/cpufreq/policy*/scaling_governor && echo '=== CPU Frequencies ===' && for p in /sys/devices/system/cpu/cpufreq/policy*; do cat \$p/scaling_cur_freq; done"

诊断结果：

NPU 频率：通过 /sys/kernel/debug/clk/scmi_clk_npu/clk_rate 查询，NPU 稳定在 1000000000 (1.0 GHz) 满频。
CPU 频率：所有 CPU 核心（大/中/小核）全部被扣在物理最低频 408MHz，Governor 为系统默认的 interactive 模式。

2. 根因剖析

NPU 在执行矩阵乘法计算时，CPU 推理线程会通过系统调用 ioctl 阻塞挂起，等待驱动返回硬件中断。
在纯净测试环境下，由于除推理外没有其他系统负载，内核的 interactive 调频器在采样窗口内计算出的 CPU 利用率极低（约 10%），调频器判定系统极为空闲，因而主动执行了降频省电。

但是，NPU 并非完全独立运行，它在输入数据拷贝（DMA）、计算图算子调度配置以及每次硬件中断返回处理等步骤上都高度依赖 CPU 核心的响应速度。当 CPU 被降频至 408MHz 时，内核处理 NPU 驱动中断的时间暴增，导致推理时延翻倍。在 AlertGateway 业务管线中，因为有图像编解码等多线程高负载，CPU 频率被动维持在高位，因而时延反而好于纯净 Demo。

二、方案探索与多轮验证历程

我们针对该调频误判设计了多轮技术方案验证，包含动态机制探索与最终的全链路锁频。

方案 1：EAS 动态频率响应（iowait boost）验证（失败）

理论依据：正确的内核协作机制应是让 NPU 驱动在等待 NPU 计算时设置 in_iowait 标志。唤醒进程时，调频器检测到 iowait 唤醒，自动触发 schedutil 调频器的 iowait boost 临时拉升频率，从而兼顾能耗与响应延迟。

排查过程：

我们检查板端 CPU 支持的 Governor 列表：

cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
# 输出：interactive conservative ondemand userspace powersave performance schedutil

将策略切换为 schedutil：

echo schedutil | sudo tee /sys/devices/system/cpu/cpufreq/policy*/scaling_governor

查看 schedutil 内部参数路径：

ls /sys/devices/system/cpu/cpufreq/policy4/schedutil/
# 输出仅有：rate_limit_us  target_load

结论：标准 Linux 主线内核中应暴露的 iowait_boost_max 等关键参数在此平台下完全不存在。这证实了 Rockchip 的 6.1.118 BSP 内核对 schedutil 进行了深度定制裁剪，剥离了 iowait boost 相关的代码路径，且 rknpu.ko 驱动的等待原语也未与 iowait 机制对接。因此该方案在当前内核生态下无法走通。

方案 2：应用层算力下限声明（UCLAMP）验证（失败）

理论依据：在 Linux 5.0+ 中引入的 UCLAMP 允许应用程序通过系统调用单方面向 CPU 调度器声明当前线程的算力配额上限与下限。在推理线程中锁定算力下限（sched_util_min），即使线程休眠，调度器依然会维持高频。

代码实现：
我们在 src/infer/InferThread.cpp 的工作线程启动时，加入如下系统调用：

#include <unistd.h>
#include <sys/syscall.h>

void InferThread::run() {
    // 线程内应用 UCLAMP util_min
    {
        // 本地定义与内核一致的 sched_attr 结构体，规避头文件冲突
        struct sched_attr_t {
            uint32_t size;
            uint32_t sched_policy;
            uint64_t sched_flags;
            int32_t  sched_nice;
            uint32_t sched_priority;
            uint64_t sched_runtime;
            uint64_t sched_deadline;
            uint64_t sched_period;
            uint32_t sched_util_min;
            uint32_t sched_util_max;
        };
        sched_attr_t attr{};
        attr.size           = sizeof(attr);
        attr.sched_policy   = 0;       // SCHED_OTHER (标准 CFS 调度)
        attr.sched_flags    = 0x20;    // 必须设置该 Flag (SCHED_FLAG_UTIL_CLAMP_MIN)，否则内核会静默忽略
        attr.sched_util_min = 512;     // 锁定算力下限为 50% (0~1024 档位)
        attr.sched_util_max = 1024;    // 允许冲到 100% 满负载

        // 274 为 aarch64 下的 __NR_sched_setattr 系统调用号
        int ret = syscall(274, 0 /* 0 代表当前工作线程 */, &attr, 0);
        if (ret != 0) {
            std::cerr << "[InferThread] UCLAMP apply failed: " << errno << std::endl;
        } else {
            std::cout << "[InferThread] UCLAMP util_min=512 applied (tid=" 
                      << syscall(SYS_gettid) << ")" << std::endl;
        }
    }
    // ... 后续推理循环 ...
}

测试验证与结果：

编译并部署该程序后，日志成功打印 [InferThread] UCLAMP util_min=512 applied。

我们在全系统处于动态节能模式下，后台对 CPU 大核（policy4）主频进行高频采样：

for i in $(seq 1 10); do cat /sys/devices/system/cpu/cpufreq/policy4/scaling_cur_freq; sleep 0.3; done

输出结果：

1200000
1416000
408000   <-- 推理阻塞时依然跌入最低物理频点
408000
1416000

结论：系统调用成功执行，但实际主频依然被动态降频拉低。分析表明，RK3588 BSP 中的调频驱动（特别是由 Rockchip 扩展出的 target_load 参数控制逻辑）绕过了 CFS 调度器原生的 uclamp 参数决策路径。该动态方案同样宣告失效。

方案 3：全链路硬锁频方案（DDR + CPUIdle + Governor 锁频）（成功）

由于无法通过动态机制绕过降频问题，我们对瑞芯微官方的 scaling_frequency.sh 进行了深度剖析，发现除了 CPU/NPU 的调频器外，还有两个极易被忽略的底层维度决定了 NPU 推理的上限：

DDR 运行频率总线带宽限制：
NPU 需要不断地从 DDR 搬运庞大的模型权重与计算激活值。系统默认 DMC（内存控制器）在 simple_ondemand 模式下，当检测到 CPU 算力占用低时，DDR 频率会动态回落（最低至 528MHz），从而饿死 NPU。必须将其锁定在 performance 模式（最高频 2.112GHz）。
CPUIdle 深睡眠唤醒延迟（C-State 抖动）：
CPU 为了节省功耗，空闲时会自动进入 cpu-sleep（状态 1），其唤醒延迟高达 220μs。由于推理线程在 CPU 与 NPU 之间存在非常频繁的中断握手，进出该状态产生的延迟累加会造成时延随机抖动。我们必须强行禁用 state1。

三、工程调优实现与部署

基于方案 3 的实测数据，我们编写了完整的自动化定频服务脚本，并在网关进程中完成了生命周期绑定。

1. 编写调优控制脚本：`rockchip_performance.sh`

该脚本在使能性能模式时备份系统当前调频参数到 /var/run/ 目录中，随后强制进行全链路锁定；在注销时能优雅还原到原始状态，实现零副作用：

#!/bin/bash
# /usr/local/bin/rockchip_performance.sh

CPU_GOVERNORS="/sys/devices/system/cpu/cpufreq/policy*/scaling_governor"
NPU_GOVERNORS="/sys/class/devfreq/*npu*/governor"
DMC_GOVERNORS="/sys/class/devfreq/dmc/governor"
CPUIDLE_STATES="/sys/devices/system/cpu/cpu*/cpuidle/state1/disable"

BACKUP_CPU_FILE="/var/run/rockchip_cpu_governor.bak"
BACKUP_NPU_FILE="/var/run/rockchip_npu_governor.bak"
BACKUP_DMC_FILE="/var/run/rockchip_dmc_governor.bak"
BACKUP_CPUIDLE_FILE="/var/run/rockchip_cpuidle.bak"

if [ "$EUID" -ne 0 ]; then
    echo "Error: Run as root." >&2
    exit 1
fi

enable_performance() {
    echo "Enabling performance mode..."
    
    # 1. 备份并锁定 CPU 核心到 performance
    local cpu_states=""
    for gov in $CPU_GOVERNORS; do
        if [ -f "$gov" ]; then
            cpu_states="$cpu_states $gov:$(cat $gov)"
            echo performance > "$gov"
        fi
    done
    echo "$cpu_states" > "$BACKUP_CPU_FILE" 2>/dev/null

    # 2. 备份并锁定 NPU 核心到 performance
    local npu_states=""
    for gov in $NPU_GOVERNORS; do
        if [ -f "$gov" ]; then
            npu_states="$npu_states $gov:$(cat $gov)"
            echo performance > "$gov"
        fi
    done
    echo "$npu_states" > "$BACKUP_NPU_FILE" 2>/dev/null
    
    # 3. 备份并锁定 DMC (DDR) 到 performance (自动获取 2.112GHz 物理上限)
    local dmc_states=""
    for gov in $DMC_GOVERNORS; do
        if [ -f "$gov" ]; then
            dmc_states="$dmc_states $gov:$(cat $gov)"
            echo performance > "$gov"
        fi
    done
    echo "$dmc_states" > "$BACKUP_DMC_FILE" 2>/dev/null

    # 4. 备份并禁用 CPUIdle 深度睡眠状态 1
    local cpuidle_states=""
    for state in $CPUIDLE_STATES; do
        if [ -f "$state" ]; then
            cpuidle_states="$cpuidle_states $state:$(cat $state)"
            echo 1 > "$state"
        fi
    done
    echo "$cpuidle_states" > "$BACKUP_CPUIDLE_FILE" 2>/dev/null

    echo "Performance mode enabled."
}

disable_performance() {
    echo "Disabling performance mode (restoring system default states)..."
    
    # 1. 还原 CPU
    if [ -f "$BACKUP_CPU_FILE" ]; then
        for item in $(cat "$BACKUP_CPU_FILE"); do
            local gov_path="${item%%:*}"
            local gov_val="${item#*:}"
            [ -f "$gov_path" ] && echo "$gov_val" > "$gov_path"
        done
        rm -f "$BACKUP_CPU_FILE"
    fi

    # 2. 还原 NPU
    if [ -f "$BACKUP_NPU_FILE" ]; then
        for item in $(cat "$BACKUP_NPU_FILE"); do
            local gov_path="${item%%:*}"
            local gov_val="${item#*:}"
            [ -f "$gov_path" ] && echo "$gov_val" > "$gov_path"
        done
        rm -f "$BACKUP_NPU_FILE"
    fi

    # 3. 还原 DMC (DDR)
    if [ -f "$BACKUP_DMC_FILE" ]; then
        for item in $(cat "$BACKUP_DMC_FILE"); do
            local gov_path="${item%%:*}"
            local gov_val="${item#*:}"
            [ -f "$gov_path" ] && echo "$gov_val" > "$gov_path"
        done
        rm -f "$BACKUP_DMC_FILE"
    fi

    # 4. 还原 CPUIdle
    if [ -f "$BACKUP_CPUIDLE_FILE" ]; then
        for item in $(cat "$BACKUP_CPUIDLE_FILE"); do
            local state_path="${item%%:*}"
            local state_val="${item#*:}"
            [ -f "$state_path" ] && echo "$state_val" > "$state_path"
        done
        rm -f "$BACKUP_CPUIDLE_FILE"
    fi
    echo "Performance mode disabled."
}

show_status() {
    echo "=== CPU Governors ==="
    for gov in $CPU_GOVERNORS; do
        [ -f "$gov" ] && echo "$(basename $(dirname $gov)): $(cat $gov)"
    done
    echo "=== DMC Governor ==="
    [ -f "/sys/class/devfreq/dmc/governor" ] && echo "dmc: $(cat /sys/class/devfreq/dmc/governor)"
    echo "=== CPUIdle state1/disable ==="
    [ -f "/sys/devices/system/cpu/cpu0/cpuidle/state1/disable" ] && echo "cpu0 state1/disable: $(cat /sys/devices/system/cpu/cpu0/cpuidle/state1/disable)"
}

case "$1" in
    enable) enable_performance ;;
    disable) disable_performance ;;
    status) show_status ;;
    *) echo "Usage: $0 {enable|disable|status}"; exit 1 ;;
esac

2. 包装为 Systemd 服务：`rockchip-performance.service`

为便于系统权限管理，我们将其写为 Systemd 系统级服务配置文件，存放在 /etc/systemd/system/ 目录下：

[Unit]
Description=Lock CPU, NPU, DMC and CPUIdle to Performance Mode
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/rockchip_performance.sh enable
ExecStop=/usr/local/bin/rockchip_performance.sh disable

[Install]
WantedBy=multi-user.target

3. 应用进程生命周期联动（无感控制）

开机自启性能服务会导致开发板长期处于高频运行态，功耗大、寿命受损。我们关闭了服务的自启链接（sudo systemctl disable rockchip-performance），转而通过修改网关的统一控制脚本 start.sh 进行生命周期绑定：

# start.sh 联动切片
case "${1:-start}" in
  start)
    if [ -f "$PIDFILE" ] && kill -0 "$(cat "$PIDFILE")" 2>/dev/null; then
      echo "AlertGateway already running (PID $(cat "$PIDFILE"))"
      exit 0
    fi
    cd "$APP_DIR"
    
    # 启动前：开启锁频服务（大核/DDR锁频，禁用cpuidle）
    echo "Starting rockchip-performance service..."
    sudo systemctl start rockchip-performance
    
    nohup "$BINARY" "$CONFIG" >> "$LOG" 2>&1 &
    echo $! > "$PIDFILE"
    echo "Started AlertGateway (PID $!), log: $LOG"
    ;;
  stop)
    if [ -f "$PIDFILE" ]; then
      PID=$(cat "$PIDFILE")
      kill -SIGINT "$PID" 2>/dev/null && echo "Stopped AlertGateway (PID $PID)"
      rm -f "$PIDFILE"
    else
      pkill -SIGINT -f AlertGateway && echo "Stopped" || echo "Not running"
    fi
    
    # 停止后：自动释放调频，恢复为默认节能降低温升
    echo "Stopping rockchip-performance service..."
    sudo systemctl stop rockchip-performance
    ;;

当程序 ./start.sh start 启动时系统自动提频；调用 ./start.sh stop 退出时自动退回动态调频并允许 CPU 深度休眠，开发板迅速降温，达成了性能与硬件能耗的最佳工程平衡。

四、联合调优实测数据对比

我们在联合调优服务部署前后，使用相同的 yolov8s.rknn INT8 模型在板端进行压力测试，得到如下数据对齐表：

1. 各优化方案平均耗时与抖动对照

优化阶段与方案配置	`rknn_run` 推理纯耗时	`total` 网关管道耗时	推理延迟抖动	发热与发热风险
A. 默认动态调频 (interactive)	~48.8 ms	—	❌ 极高 (Jitter明显)	🟢 冰凉 (无风险)
B. 全核锁频 (CPU/NPU performance)	~34.8 ms	~38.0 ms	🟡 极小 (基本平滑)	🔴 高发热
C. 大小核差异化锁频 (大核perf, 小核节能)	~33.8 ms	~37.0 ms	🟡 极小 (基本平滑)	🟡 较低
D. 全链路锁频 (DDR+CPUIdle+大核锁定)	~29.4 ms	~31.9 ms	✅ 零波动 (方差近乎为0)	🔴 偏高 (推荐主动散热)

2. 方案 D (全链路锁频) 下的网关运行日志切片

[Infer] cpu:1.06 cpy:0.11 npu:29.43 cnv:1.34 total:31.95 ms objs:0
[Infer] cpu:0.99 cpy:0.10 npu:29.35 cnv:1.35 total:31.79 ms objs:0
[Infer] cpu:1.02 cpy:0.11 npu:29.41 cnv:1.34 total:31.92 ms objs:0

相较方案 C 的 ~33.8ms 时延，DDR 锁频与 CPUIdle state1 禁用的加入直接使推理用时再度压低 13%，同时 cnv（YOLOv8 后处理）与 cpy（图像 DMA 拷贝）的时延稳定性也得到了极大的提升，彻底为 30 FPS (33.3ms) 实时管线解除了硬件时延瓶颈。

五、总结与嵌入式开发避坑指南

不要低估 DDR 频宽对 NPU 的限制：在大量计算中，数据往往卡在 DDR 搬运到 NPU 的路上。性能调优必须将 DMC（内存控制器）纳入管理，将其锁在最高频运行。
深度休眠（CPUIdle）也是抖动源：深度 C-State 的 220μs 唤醒时延，对于微秒级高频中断响应的神经网络算子流是不可接受的，需主动限制其只能在浅睡眠（WFI）状态。
重视 BSP 定制化内核与主线的行为冲突：在定制嵌入式平台上直接套用 UCLAMP、iowait 等主线文档参数往往存在“调频器覆盖屏蔽”的隐蔽陷阱，必须通过实采频率进行功能闭环。

项目完整源码与调优脚本配置已开源： https://github.com/johnjiamzhong-project/AlertGateway

posted @ 2026-07-03 16:47 rambos1996 阅读(92) 评论(0) 收藏举报

刷新页面返回顶部

johnrambos

[深度硬核] RK3588 边缘计算网关性能调优：NPU 推理延迟波动定位与 CPU/DDR/CPUIdle 联合调优实践

一、背景与反常现象分析

1. 现场诊断：CPU 状态采样

2. 根因剖析

二、方案探索与多轮验证历程

方案 1：EAS 动态频率响应（iowait boost）验证（失败）

方案 2：应用层算力下限声明（UCLAMP）验证（失败）

方案 3：全链路硬锁频方案（DDR + CPUIdle + Governor 锁频）（成功）

三、工程调优实现与部署

1. 编写调优控制脚本：`rockchip_performance.sh`

2. 包装为 Systemd 服务：`rockchip-performance.service`

3. 应用进程生命周期联动（无感控制）

四、联合调优实测数据对比

1. 各优化方案平均耗时与抖动对照

2. 方案 D (全链路锁频) 下的网关运行日志切片

五、总结与嵌入式开发避坑指南

公告

johnrambos

[深度硬核] RK3588 边缘计算网关性能调优：NPU 推理延迟波动定位与 CPU/DDR/CPUIdle 联合调优实践

一、 背景与反常现象分析

1. 现场诊断：CPU 状态采样

2. 根因剖析

二、 方案探索与多轮验证历程

方案 1：EAS 动态频率响应（iowait boost）验证（失败）

方案 2：应用层算力下限声明（UCLAMP）验证（失败）

方案 3：全链路硬锁频方案（DDR + CPUIdle + Governor 锁频）（成功）

三、 工程调优实现与部署

1. 编写调优控制脚本：rockchip_performance.sh

2. 包装为 Systemd 服务：rockchip-performance.service

3. 应用进程生命周期联动（无感控制）

四、 联合调优实测数据对比

1. 各优化方案平均耗时与抖动对照

2. 方案 D (全链路锁频) 下的网关运行日志切片

五、 总结与嵌入式开发避坑指南

公告

一、背景与反常现象分析

二、方案探索与多轮验证历程

三、工程调优实现与部署

1. 编写调优控制脚本：`rockchip_performance.sh`

2. 包装为 Systemd 服务：`rockchip-performance.service`

四、联合调优实测数据对比

五、总结与嵌入式开发避坑指南