RK3588双路视觉QoS严格优先调度架构解析

项目走到“双路视觉方案二、阶段四”这个位置，说实话已经到了一个挺微妙的地方。系列前17篇做了大量基础工作：环境搭建、NPU驱动适配、yolov5s的ONNX导出与rknn转换、双路MIPI-CSI取流、两路推理线程的基本调度、以及三轮基于延时考核的信号机制。到了阶段四，整个项目的重心从“能跑、能看、能出结果”正式切换到“如何在一颗RK3588上让两路视觉任务都拿到确定性的算力与带宽”。这一篇要解决的问题很具体——把原先“谁先抢到谁先用”的调度逻辑，替换成一套真正意义上的QoS严格优先机制。核心关键词是QoS、严格优先、双路视觉、内存-缓存编排调度，我会把从需求拆解、算子路径分析、RGA/NPU/NEON三类资源协同、SHM-Pool预制高优先级算子，到最后的帧时戳统计与丢帧排查，完整拉一遍。

1. 内容整体设计与思路拆解

1.1 为什么阶段三的三轮信号机制不够用了

阶段三那套调度器，本质上是给两路相机各开一个线程，利用三轮考核信号做一个先后判断：第一轮两个线程同时抢一个全局锁，谁先拿到谁就先走完整条yolov5s的推理链路，另一路等它释放完再走。这个机制在延时敏感度要求不高的验证场景里确实能用，两路一前一后、错峰执行，总吞吐量还算过得去。但一旦把“一路必须严格优先于另一路”作为硬性需求，这套机制的第一个问题就暴露出来：锁的竞争完全靠运气。线程何时被唤醒、何时拿到锁、何时让出CPU，都不受任务优先级控制，结果就是在高优先级任务赶时间的节骨眼上，反而经常被低优先级任务的长链路占着NPU和内存带宽。

第二个问题更麻烦：三轮考核信号只看“是否轮到我执行”，完全不看当前算子的优先级属性。比如说低优先级这一路的yolov5s已经跑到了后处理阶段，正在做NMS和类别过滤，此时高优先级的一路正好需要NPU做前向推理——两路同时压向有限资源时，三轮信号机制没有能力做“立即剥夺、优先供给”，只能等低优先级跑完。

我打个比方，阶段三的调度器像餐厅里只有一个厨师、两桌客人都点了同一道菜，谁先喊“我要”就先做谁的；阶段四要做的严格优先，是把其中一桌升级成“VIP加急”，不光要优先做他们的菜，还要保证厨房的灶台、水槽、备菜台随时给这桌留着。

1.2 阶段四“严格优先”到底在管理什么资源

很多刚开始做RK3588多路视觉的朋友，第一反应是“把一路线程设成高优先级不就行了”。确实，Linux的pthread_setschedparam可以给线程设置SCHED_FIFO和较高优先级，但只调这个远远不够，因为RK3588上的推理链路根本不是纯CPU计算，整个yolov5s的处理过程至少横跨三类硬件资源：

• NPU（RKNN NPU）：负责模型前向推理，也是整个链路中单帧耗时占比最高的一段；
• RGA（2D图形加速器）：负责图像缩放、格式转换、ROI裁剪，双路视觉几乎每帧都要走RGA；
• CPU（NEON/ARM核）：负责前处理里的部分像素操作、后处理里的NMS和结果解析。

如果只把CPU线程优先级调高，结果就是：高优先级线程确实更早拿到CPU核，但它刚把数据丢给NPU，低优先级那一路的NPU请求也同时进来了。RKNN在驱动层如果不做优先级区分，两块任务在NPU内部依然是排队执行。等于你让VIP客户先进了餐厅门，但后厨的菜还是按先来后到的顺序炒。

阶段四要做的严格优先，核心思路就是把Pipeline改成按算子拆分的部署形态，而不是按“整路推理”来调度。把两路视觉任务拆成“取流/前处理/推理/后处理”四段，每一段独立成一个可调度单元，再给每个单元标注QoS等级，调度器按等级决定谁先占用资源、谁可以被抢占、谁只能拿剩余带宽。

1.3 这套思路与单纯的“线程优先级”有什么本质区别

线程优先级解决的是“谁先运行”，而QoS严格优先解决的是“谁先获得完成一帧所需的所有资源”。两者看着像，实际上差了一整个维度。我在实现里给两路视觉任务定义了从P0（最高）到P2（最低）三个QoS级别，P0级任务（比如主相机、安全检测通道）不仅要优先占用CPU核，还需要在NPU请求队列里插队，在RGA请求里抢占带宽，在内存层面锁定SHM区域防止被换出。这些操作是pthread_setschedparam完全无力覆盖的。

所以阶段四的整体设计思路可以概括成三步：第一步做算子切片，把整条链路拆成可独立调度的小段；第二步给算子标QoS，明确每一段的优先级属性；第三步建内存-缓存编排调度器，统一仲裁CPU、NPU、RGA三方的资源分配。这里的“内存-缓存编排调度器”我是参考了一些工业级调度器的思路，简化后落地到RK3588上，后面会把代码逻辑和数据结构都贴出来。

1.4 这次改造预期的量化收益

动手之前我给自己定了个不算激进的目标：高优先级一路的P95端到端延时从原来的55ms压到35ms以内，低优先级一路在完全空闲时可以复用全部推理能力跑到接近满速，但一旦高优先级任务有帧进来，低优先级必须在5ms内让出NPU和带宽资源。此外还有一个硬性约束——双路同时开启时的总吞吐不低于改造前的85%，不能让严格优先变成“单向独享”，否则失去了双路视觉的意义。

这组目标线下文会逐项验证，先说明白：当前双路yolov5s单帧端到端延时基线大约在48ms~60ms之间，瓶颈主要集中在RKNN前向推理和RGA缩放这两段。接下来先拆一拆yolov5s算子在RK3588上的真实执行路径，因为不理解算子路径，后面所有的QoS映射都是空中楼阁。

2. yolov5s算子在RK3588上的三类执行路径与QoS映射逻辑

2.1 一帧图像从MIPI到输出结果，完整经过哪些算子

先说双路视觉的一条完整链路：MIPI-CSI摄像头采集到RAW或YUV图像后，经过V4L2驱动进入DDR，随后进入ISP或直接送RGA做格式转换与缩放——如果你用rknn_toolkit2的rknn.config设置了target_platform='rk3588'，典型的前处理会把YUV420SP先转成RGB，再缩放成模型输入尺寸640x640；然后数据从DDR拷入NPU的输入张量，经yolov5s的卷积、C3、SPPF等算子完成前向推理，输出候选框；最后在CPU上跑NMS、置信度过滤、坐标换算，把结果映射回原始图像坐标，叠加显示或推流。

这条链路里，真正能被“调度”干预的，是数据在CPU、RGA、NPU、DDR之间移动和执行的先后次序。yolov5s的网络结构本身我们是不能改的（改了就要重新训练），但网络在哪里执行、什么时候执行、执行完数据放哪，完全是工程上可以控制的。

2.2 RKNN推理内部与RGA/NEON三条路径的耗时画像

我整理了一份实测耗时画像，环境是香橙派5（RK3588），8GB内存版本，双路MIPI-CSI输入，yolov5s用rknn-toolkit2 1.6.0版本转换，NPU跑INT8量化。耗时数据是100帧的平均值：

这里面有个很关键的点：RGA和NPU都是独立的硬件单元，它们在执行时CPU大部分时间是空闲等待状态，但也需要CPU发起请求、等待完成信号。所以调度器真正要仲裁的不是“CPU核够不够”，而是DDR带宽和硬件执行队列——RGA一张缩放任务通常要读写几十MB数据，NPU一次前向推理也要搬运几十MB权重和特征图，两路同时跑起来DDR带宽瞬间吃紧。这也是为什么阶段四我把调度器的名字定为“内存-缓存编排调度器”（下称MC-Cluster Scheduler），核心控制对象就是共享内存池和DDR访问节拍。

2.3 从QoS等级到三类执行路径的映射规则

我定义了三个QoS优先级等级，对应不同视觉通道的业务属性：

• P0（QoS高）：主检测通道，例如驾驶员监控、安全门禁，这类通道的输出直接影响告警和决策，不允许延迟抖动；
• P1（QoS中）：辅助检测通道，例如客流统计、行为分析，可以允许最高10ms级的抖动，但长时间延迟不可接受；
• P2（QoS低）：背景录像、环境监控，这类通道只要求最终不丢帧太严重，短时让出资源完全没问题。

映射到算子执行路径上，我的规则是这样：

• P0任务的所有算子（RGA缩放、NPU推理、NMS）都被标记为“不可抢占”，调度器保证它们一进入执行队列就处于最前部；
• P1任务算子在P0空闲时按正常队列执行，一旦P0有请求到达，P1正在执行的RGA/NPU任务允许被“等待完成但不再继续排新任务”；
• P2任务则彻底作为带宽填充者，只在P0和P1都没有待执行算子时才获得DDR带宽和硬件单元。

也就是说，严格优先不是简单地把一路线程设成高优先级，而是做到“在任意时刻，只要P0任务有算子要执行，P1和P2的算子都必须让路”。实现这一点的关键，是放弃阶段三那种“整条链路一把锁”的做法，改成一个全局算子就绪表（Op-Ready Table），每个算子完成后更新表项，调度器按QoS顺序扫描表项并派发到对应硬件单元。

2.4 为什么说优先级最终要映射到内存墙而不是CPU核

这里我要说一个大家容易忽略的事实。在RK3588上跑yolov5s双路，CPU核往往是用不满的——6个A55小核中有4个长期处于低负载，2个A76大核在等NPU和RGA回调。真正的瓶颈第一是RGA单元（只有一个），第二是NPU队列深度，第三是DDR带宽。

拿DDR带宽举个例子：RK3588的LPDDR4X理论带宽约34GB/s，听起来很大，但双路1080p@30fps的输入流每秒要写入约1.2GB的原始帧数据，再加上yolov5s每帧推理要读取权重（约7.1MB的INT8模型）和特征图（每层几MB到十几MB不等），一帧推理的数据搬运量大约在150MB~200MB。双路同时推理时，RGA又要在DDR里做中间缓冲，整体带宽利用率可以轻松到60%以上。如果P2任务正在做高强度的带宽消耗（比如同时在做第三路的录像编码），P0任务的推理就被“内存墙”拖慢了，表现为NPU明明空闲但前向推理的实际完成时间变长。

所以阶段四的调度器里，我给每个QoS等级配了独立的内存访问权重：P0是DDR_BW_HIGH，P1是DDR_BW_MEDIUM，P2是DDR_BW_LOW，通过RK3588的DDR控制器支持的带宽分配接口（在设备树中配置dfi相关节点做软限速），给P0任务“钉住”带宽。这个后面会展开讲配置。

3. MC-Cluster Scheduler核心设计与实现

3.1 从TDS到HOOK：改造后的调度器架构

阶段三的调度器我内部叫TDS（Thread-Delay Scheduler），核心是一个全局互斥锁加三轮信号量。阶段四的MC-Cluster Scheduler（MC-CS）在架构上做了很大的调整，核心组件变成三个：

第一，算子就绪表（Op-Ready Table，ORT）。这是一张全局哈希表，key是“通道ID+算子ID”，value是算子的状态（WAITING、READY、RUNNING、DONE）、QoS等级、预计执行时间、数据缓冲区地址。两路任务每完成一个阶段，就更新自己的表项，调度器通过扫描表项决定下一步派发。

第二，硬件单元队列仲裁器（HW Unit Arbiter）。针对RGA和NPU这两个共享硬件单元，我各维护了一个优先队列。队列里的元素是“算子请求”，排序规则是QoS等级优先，同等级按时间戳先来后到。P0请求到达时会直接插到队首，P1到达时插到所有P2前面，P2只能在队列尾部排队。同时，对于正在执行的P1/P2算子，仲裁器支持“软抢占”模式——等当前算子把正在执行的批次跑完，立即停发新批次，把硬件让给P0。我从实测中发现，RKNN的NPU驱动在批量推理模式下无法在批次中途打断，所以“软抢占”已经是最优解；RGA则支持更细粒度的任务分割，可以在任务边界做打断。

第三，调度策略引擎（Policy Engine）。这是QoS“严格优先”语义的核心。它不只管排序，还监管每路任务的“预算”。我给每路设置了一个周期预算：P0每50ms必须完成一帧端到端推理，P1每80ms至少完成一帧，P2的交付时间不设硬上限但丢帧率不能超过30%。策略引擎每个周期检查各路的实际交付情况，如果P0连续两个周期没有达标，调度器会强制压缩P1的带宽配额并暂停P2任务一段时间，保证P0回血。

这三个组件合在一起，构成了一个可以真正落地到RK3588上的调度闭环。代码层面我用的是C++17，线程模型是std::thread+ 原子变量，统一由MCCluster::submit()接口提交任务。

3.2 QoS标记与调度器API设计

给算子标QoS，听起来简单，但落地时要注意粒度。我的建议是按“算子组”标记，而不是每个函数或每个循环都标。因为如果粒度太太细，调度器的上下文切换开销会吃掉收益；如果太粗，又回到整条链路一把锁的老路。我最终按以下五组算子划分：

调度器对外主要暴露三个接口：

// 注册一路视觉任务，返回通道ID int mc_add_channel(const std::string& name, int qos_level); // 提交一个算子组到调度器，指定所属通道和算子组ID void mc_submit_op(int channel_id, int op_group_id, std::shared_ptr<OpContext> ctx); // 设置某通道的QoS等级（运行中可调） void mc_set_qos(int channel_id, int new_qos_level);

在mc_submit_op内部，调度器会做几件事：给算子分配一个唯一的OpID，写入ORT表，根据QoS等级内容插入硬件单元队列，然后唤醒对应硬件单元的worker线程去执行。每个worker线程在拿到算子后，调用真正的执行函数（比如RGA的rk_mpi_rga接口或RKNN的rknn_run接口），执行完成后再回写ORT表状态，并检查是否有更高优先级的算子已经进入等待队列。

整个调度器我自己跑下来，每个算子的调度开销大约在10微秒到20微秒级别，相对于RGA的12ms和NPU的28ms完全可以忽略。

3.3 预制高优先级算子SHM-Pool的实现细节

单纯做调度还不足以实现真正的“严格优先”，因为数据复制也会成为瓶颈。假设P0通道的RGA算子已经完成缩放，下一步要把640x640的图像数据从RGA输出缓冲区搬给NPU输入。如果这些缓冲区是运行时临时分配的，P0算子在拷贝数据时可能会跟P2算子的DDR访问互相挤占；更糟的是，内存分配器（glibc的malloc）在并发场景下可能会有锁竞争。

所以我在实现里做了一个预制高优先级算子SHM-Pool（共享内存池）：在系统启动阶段，为P0通道预分配一组固定大小的内存块，专门存放RGA输出、NPU输入、NMS输入等中间数据。因为这些内存在启动时就已锁定（mlock防止换页），物理地址固定，后续P0算子只需要从池里“拿块”而不是“分配块”，这就杜绝了运行时的内存分配延迟。

SHM-Pool的实现分三步：

第一步，创建共享内存池。用shm_open创建一个文件描述符，ftruncate到所需大小，再mmap到进程地址空间。我开的池大小是64MB，其中包含32块2MB的缓冲区。2MB是怎么算出来的？640x640x3字节的RGB数据大约1.2MB，加上对齐开销和RKNN输入头，2MB够了。32块是为了支持P0在极端情况下排队多个算子而不互相覆盖。

第二步，给每块做索引表。池内每块内存有一个状态位（FREE/IN_USE）和一个归属字段（当前属于哪个通道的哪个算子）。P0算子申请时，调度器用无锁的原子CAS把某一块从FREE置为IN_USE。注意这里不能用malloc或者sbrk，我就是用原子操作管理数组索引，实测下来单次申请在100ns内完成。

第三步，物理锁定。对整块池调用mlock，把内存钉在物理RAM中，避免操作系统把它换出去。这一点对实时性至关重要，因为P0帧在推理过程中如果发生page fault，直接就可能产生毫秒级延迟，在延时敏感场景是不能接受的。

代码片段示意如下：

class SHMPool { public: void* acquire(int needed_bytes) { for (int i = 0; i < kBlockNum; i++) { // 无锁CAS，确保只有当前线程能拿到该块 if (blocks_[i].state.compare_exchange_strong(kFree, kInUse)) { return blocks_[i].addr; } } return nullptr; // 池满，需要调用方处理 } void release(void* ptr) { int idx = ((char*)ptr - (char*)pool_base_) / kBlockSize; blocks_[idx].state.store(kFree); } private: struct Block { std::atomic<int> state; void* addr; }; // mmap后的基地址 void* pool_base_; Block blocks_[kBlockNum]; };

这里有个经验要分享：池子开多大一定要根据推理pipeline的中间张量大小来算，不要拍脑袋。我一开始给P0开了128MB，结果双路都启动后频繁触发内存紧张，反而导致调度器在分配时等待。后来算了一笔账，P0最多同时有两帧在流水线里（一个在RGA，一个在NPU），单帧中间数据一共约4MB（RGB输出1.2MB + NPU输入1.2MB + 两路临时缓冲约1.5MB），一个64MB池已经能同时覆盖8帧的中间数据，完全够用。

3.4 QoS严格优先策略的落地流程与实测侧写

把上面所有组件串起来，阶段四的P0优先策略落地流程可以归纳为五步：

1. 系统启动时初始化MC-Cluster Scheduler，创建ORT表、硬件队列和SHM-Pool，等待通道注册；
2. 主程序注册两个通道：通道0（主检测）标记P0，通道1（辅助监控）标记P1；
3. 两路各自创建“取流线程→RGA线程→NPU线程→NMS线程”的流水线，所有线程通过mc_submit_op()提交算子组，而不是直接调用rknn_run或RGA接口；
4. 调度器根据ORT表状态和QoS优先队列逐级派发：P0的RGA请求永远排在RGA硬件队列第一位，P0的NPU请求同理；P1任务只在P0无请求时可获得硬件单元；
5. 策略引擎每50ms检查一次P0通道的“最近完成帧时戳”，如果不达标，自动收紧P1和P2的DDR带宽配额。

这套流程实现后，我跑了一轮压力实测：两路都是1080p@30fps输入，P0通道连续检测画面中的人形目标，P1通道只做画面录制和简单背景建模。实测数据如下：

最让我满意的其实是P0最大单帧抖动从21ms降到了6.8ms。因为端到端延时均值不重要，真正影响视觉告警体验的是“某一帧突然变慢”的抖动——在安全监控场景里，这往往意味着事件已经发生但检测结果还没出来。

4. 三块实操硬骨头：RKNN驱动、RGA共享、DDR带宽控制

4.1 RKNN驱动侧：NATIVE接口与批量提交的取舍

RKNN推理本身在调度器里是最难“严格优先”的，因为NPU驱动固化了队列模型。rknn-toolkit2提供两种典型的推理提交方式：rknn_run（单个推理）和rknn_run_batch（批量推理）。批量推理吞吐更高（NPU可以复用权重加载），但问题是一旦进入批量模式，这批里的所有帧都会作为一个整体执行，P1和P2的帧如果混进去了，P0的帧就只能排在后面，无法“插队”。

我在阶段四里采用了“P0独立批量、P1/P2共享批量”的策略：P0通道的推理请求形成单独的批量队列，批量大小通常为1（也可以为2-3帧，视任务强度），保证P0的rknn_run_batch一提交就占据NPU队列最前位置并在权重加载完成后立即执行；P1和P2通道则合并成另一个批量队列，在P0没有任务时提交。同时我利用RKNN的rknn_set_core_mask把P0的推理绑定到NPU的特定核（比如core 0/1），P1/P2绑定到core 2/3，在NPU内部做物理隔离。这里需要提醒：RK3588的NPU有3个核，不同核之间确实可以并行跑不同模型，但共享同一份DDR带宽，所以核隔离解决的是队列抢占，解决不了带宽挤占。

4.2 RGA：双路缩放是隐藏的系统性瓶颈

另一个实操时容易翻车的地方是RGA。很多人以为yolov5s的瓶颈一定在NPU，我最初也这么以为，逐项测了才发现RGA在双路场景下才是最先接近饱和的。原因很简单：RK3588只有一路RGA2.0硬件单元，同一时刻只能做一个2D任务。双路1080p输入，每帧都要做YUV转RGB + 缩放 + 可能的ROI裁剪，这些操作全都要排队过RGA。P0和P1两路同时提交RGA任务，RGA驱动自带一个FIFO，谁先提交谁先执行——这跟QoS没有任何关系。

为了做“严格优先”，我给RGA加了一层用户态排队。具体做法是用mpp的RGA接口封装一个RgaQueue，内部包含一个优先队列，跟调度器的HW Unit Arbiter对接。P0的缩放请求直接push_front，P1的请求正常排队，P2的请求在队尾。实测下来P0的RGA等待时间从平均2.7ms降到了0.4ms以下。不过也得承认，RGA任务无法真正硬抢占，如果P2已经开始执行一次大图缩放，P0不能把它“拽回来”，只能等它做完当前任务。所以我的原则是：永远不要让P2级任务发起大尺寸缩放，P2通道的输入帧先粗降采样到960x540，再做格式转换，把单次RGA任务时间压到2ms以内，这样P0即便遇到RGA占用，最坏等待也就2ms。

4.3 DDR带宽控制：设备树与实时监测

DDR带宽这块，RK3588的TRM文档讲得很含蓄，没有暴露特别精细的用户态编程接口，但设备树里可以配置DMC（Dynamic Memory Controller）的带宽分配策略。我在方案里用的是“设置dfi_bw权重+rt_monitor监控”的方式，让P0对应的内存区域获得更高的DMC仲裁权重。

具体到设备树修改，我在/sys/kernel/debug/dri/0/summary下能看到每路的内存带宽占用，通过调节QOS_PRIORITY寄存器可以给不同设备设不同的服务质量等级。RGA和NPU在RK3588的SIP（System Integration Platform）里都挂了QoS模块，理论上可以给NPU的AHP端口、RGA的AXI端口设不同的QOS_CTRL值，P0对应的高优先级设备的QOS值设到最高（比如15），P2设到最低（比如1）。这个操作我没敢在生产环境长期开，因为设备树改动会影响整个系统的内存调度，但做过一轮短时验证：P0在DDR竞争激烈时端到端延时从40ms下降到34ms，效果明显。如果你的项目对DDR带宽控制有硬性要求，建议在测试环境充分验证后再上生产。

4.4 一个容易被忽视的GPU与显示叠加问题

双路视觉方案后期多半要接显示输出，这就会牵扯到GPU。虽然yolov5s的推理链路用不到GPU（NPU扛了），但显示叠加层（overlay）和QT/eglfs渲染会用GPU。GPU驱动在RK3588上跟NPU类似，也走Command Queue，也有优先级概念。阶段四里我也给显示线程设了P1优先级，避免P0推理时画面掉帧导致操作员看不到实时结果。实测下来这个小改动带来的体验提升非常大——之前P0满负荷推理时显示帧率从30fps掉到22fps，加上GPU优先级控制后稳定在了29fps左右。

5. 常见问题与排查技巧实录

5.1 问题一：P0优先级提升了，但NPU推理时间反而变长

排查思路：先看NPU核的占用情况。我最初把P0的推理批量大小设为1，想着单帧占比最小、等待最短。结果发现P0单帧在NPU上的执行时间反而从28ms涨到32ms。后来用rknn_query查NPU负载，发现单帧批量推理时NPU对权重加载的复用率太低，模型权重（约7MB）几乎每帧都要从DDR重新加载，带宽浪费严重。解决办法是把P0的批量大小调整为3帧——也就是P0通道内部先攒够3帧再一起提交，这样权重加载只做一次，分摊到每帧的成本大幅下降。代价是P0的“首帧响应延迟”会略增约3ms，但P50和P95都变好了。这就是典型的需要在单帧延迟和吞吐之间权衡的案例。

5.2 问题二：SHM-Pool频繁满池导致P0算子等待

排查思路：看ORT表里P0各算子的持续时间。我发现P0通道的NMS阶段经常等NPU输出拷贝回CPU内存，因为我在NMS阶段把输出数据从NPU输出缓冲区拷贝到CPU内存时，直接用了普通memcpy。P0的中间输出是1x25200x85的张量，约8.5MB，这个拷贝在双路同时读写内存时会拖慢。后来改成在SHM-Pool里为NPU输出单独预留一块8MB缓冲区，并配合NEON向量化的批量拷贝，把拷贝时间从4ms压到1.8ms。这个优化的本质是：不要用通用的内存拷贝，要为高优先级算子做专属的搬运路径。

5.3 问题三：调度器自身线程引发死锁

调度器设计时我在ORT表里用了大量原子变量，理论上无锁，但在调试早期出现过一次死锁。原因是调度器线程在等待P0算子完成时，自己也去抢了同一个硬件单元的队列锁。后来我安全地梳理了加锁顺序，核心原则是：硬件单元锁永远不嵌套持有，调度器线程持锁期间绝不等待任何算子完成，发现问题出在NMS回调里又调用了mc_submit_op，触发了锁重入。加了一个“调度器线程专用快速路径”后解决：调度器线程提交算子时不排队，直接插到队列头并且不加锁（因为只有一个调度器线程），普通线程仍然走带锁路径。

5.4 常见问题速查表

6. 在香橙派5上落地的几个补充经验

6.1 关于香橙派5与RK3588适配的一些心得

香橙派5这块板子最近在开发者里讨论热度很高，论坛里经常有人问“rk3588能不能跑yolov8”“香橙派5pro是不是更好”，我先说说我的判断。如果你手里已经有香橙派5标准版（RK3588、8GB内存），做双路视觉推理是非常合理的选型；但如果你还没买板子，建议优先考虑带更大内存的版本或香橙派5Pro，因为双路视觉加调度器、加显示叠加、加录像编码，8GB内存在极端场景下会出现紧张。另外，香橙派5的散热设计不错，但长时间跑双路NPU推理必须加主动风扇，否则NPU降频后P0延时直接翻倍，所有调度策略全部失效。

6.2 移植到yolov8时不要重复造调度器的轮子

现在开源社区讨论“rk3588部署yolov8”的帖子很多，我也试过把方案里的yolov5s替换成yolov8n。yolov8n的算子结构相比yolov5s有变化——C2f模块替代了C3，SPPF也做了调整，导致RKNN转换后单帧推理时间大约从28ms降到23ms（得益于更轻量的结构）。但这对调度架构几乎没有影响：因为调度器是面向算子组的，不是面向具体网络的。你只需要改OP_NPU_INFER里调用的rknn模型句柄，以及后处理里的解码逻辑，调度器、SHM-Pool、QoS映射全部复用。所以我的建议是：先跑通方案，再动模型结构，不要一上来就换yolov8——模型轻量化是性能甜点，调度架构稳定才是把双路视觉做得可靠的地基。

6.3 记录每个帧时戳，不要相信默认调度

最后分享一个长期调试里最有用的习惯：从阶段四一开始，我就给每个进入pipeline的帧打了四段时戳——取流完成时刻、RGA完成时刻、NPU完成时刻、NMS完成时刻。每段时戳分别记录“提交时间和完成时间”，这样调度器在哪一段把帧卡住，看时戳就能精确定位。不要光看端到端延时，因为端到端延时只会告诉你“慢了”，不会告诉你慢在哪一段。我在优化P0延时时，就是靠时戳发现RGA等待时间占了4.2ms，然后才去改造RGA队列的。这个习惯强烈建议所有做多路视觉的朋友都保留。

还有一个产品化层面的小建议：QoS等级不要设成固定值，做成可动态调整的接口。比如白天主检测通道是P0，到了夜间可以把录像通道提升为P1、把主检测降为P1，因为夜间事件少、检测压力低。调度器支持运行时mc_set_qos()之后，这种业务切换非常顺滑。

双路视觉走到阶段四，QoS严格优先算是把RK3588的硬件底子吃透了一层。从编排调度架构到SHM-Pool再到DDR带宽控制，每一步都在跟硬件特性较劲，但结果的确定性提升是实打实的。这里面的核心体会是：在RK3588上做多路视觉，真正的工作量不在算法本身，而在把算法链路按算子切片后，用一套可靠的调度机制把CPU、RGA、NPU、DDR四个资源的节奏捏在一起。阶段四的这套MC-Cluster Scheduler我还在继续调优，后续如果做了动态QoS和调度策略自适应的部分，再单独写一篇出来。