📚 课程目录第3章线程调度基础

3、线程调度基础：操作系统线程模型、线程池原理、CPU亲和性、调度策略概述

ONNX Runtime 在端侧（移动端、边缘设备、嵌入式 Linux）执行推理时，线程调度直接决定了延迟的稳定性和吞吐上限。端侧 CPU 核心数有限（通常 4~8 核），且大小核架构（如 ARM DynamIQ）普遍存在，若不了解操作系统线程模型与调度策略，很容易出现“线程数设得越多推理越慢”的反直觉现象。本章从操作系统线程模型出发，逐步拆解线程池原理、CPU 亲和性设置以及调度策略的选择逻辑，为后续章节的延迟调优打下理论基础。

3.1 操作系统线程模型：从进程到线程的演化

在 Linux 内核视角中，线程本质上是“轻量级进程”（LWP），它共享进程的地址空间、文件描述符和信号处理表，但拥有独立的栈、寄存器上下文和调度实体。理解线程模型的关键在于内核调度实体（KSE，Kernel Scheduling Entity）与用户线程的映射关系。当前主流 Linux 内核采用 1:1 模型，即每个用户线程对应一个内核线程，由内核统一调度。这种模型实现简单、调度公平，但线程创建/销毁开销较大（约 10~20 微秒），且上下文切换需要陷入内核态。

ONNX Runtime 的端侧推理引擎（如 XNNPACK、NNAPI 后端）通常不直接创建裸线程，而是通过线程池封装。线程池的核心价值在于复用：预先创建固定数量的工作线程，通过任务队列分发计算任务，避免频繁 pthread_create/pthread_join 的系统调用开销。在移动端场景下，线程池大小通常设置为 std::thread::hardware_concurrency() 或根据 CPU 核心数手动指定，但直接使用该值往往不是最优解——因为端侧 CPU 存在大小核异构，且推理任务本身有并行度上限。

线程模型	映射关系	优点	缺点	适用场景
1:1 模型（KSE）	用户线程 = 内核线程	实现简单、调度公平、无用户态调度器	创建/切换开销大	Linux 默认、ONNX Runtime 默认
M:N 模型	多用户线程映射到少内核线程	创建开销小、内存占用低	调度复杂、易出现优先级反转	Go runtime、部分协程库
混合模型	部分线程 1:1，部分 M:N	兼顾性能与灵活性	实现复杂度高	JVM、Erlang VM

  关键判断方法：在 Android/Linux 端侧，使用 ps -T -p <pid> 查看进程内线程数，或通过 /proc/<pid>/task/ 目录统计线程数量。若线程数远大于 CPU 核心数，说明线程池配置可能过度订阅（oversubscription），导致上下文切换频繁。

3.2 线程池原理：任务队列与工作线程的协作机制

ONNX Runtime 的线程池（onnxruntime::concurrency::ThreadPool）采用经典的生产者-消费者模型。核心组件包括：一个互斥锁保护的阻塞队列、若干工作线程、条件变量用于唤醒等待线程。当推理任务（如算子执行、张量拷贝）被提交到线程池时，调度器将任务封装为 std::function 对象放入队列，工作线程从队列头部取出任务执行。线程池的关键参数有三个：核心线程数（保持存活）、最大线程数（允许扩容上限）、任务队列容量（背压控制）。

在端侧推理场景中，线程池的调优重点不是“扩容”，而是“避免阻塞”。例如，当某个算子（如 Conv）内部调用 BLAS 库时，BLAS 自身可能创建线程，导致线程池嵌套膨胀。此时应设置 OMP_NUM_THREADS=1 或使用 openmp 的 proc_bind 选项，确保算子内部不额外创建线程。另一个常见问题是任务粒度：若单个任务执行时间过短（小于 5 微秒），线程池的锁竞争和唤醒开销将超过任务本身的计算时间，此时应合并任务（如将多个小算子合并为一个任务）。

// ONNX Runtime 线程池配置示例（C++ API）
Ort::SessionOptions session_options;
session_options.SetIntraOpNumThreads(4);      // 算子内并行线程数
session_options.SetInterOpNumThreads(1);      // 算子间并行线程数（端侧通常设为1）
session_options.SetExecutionMode(ExecutionMode::ORT_SEQUENTIAL); // 顺序执行避免竞争

经验值：端侧 CPU 推理时，intra_op_num_threads 建议设置为“性能核心数 + 1”或直接等于性能核心数。例如骁龙 8 Gen 2 的 4 颗大核，可设为 4；若同时运行其他后台任务，可减至 3。切勿设置为总核心数（8），否则小核参与计算反而拉高延迟。

3.3 CPU 亲和性：绑定核心与隔离干扰

CPU 亲和性（CPU Affinity）决定了线程允许在哪些 CPU 核心上运行。在端侧大小核架构下，设置亲和性可以带来三个直接收益：缓存命中率提升（线程固定在同一核心，L1/L2 缓存不迁移）、调度延迟降低（避免线程在不同核心间迁移）、关键任务隔离（将推理线程绑定到大核，避免与小核上的后台任务争抢）。Linux 提供 sched_setaffinity() 系统调用，Android 还提供了 android_set_thread_priority() 和 set_cpuset_policy() 等封装。

在 ONNX Runtime 中，可以通过 Ort::ThreadingOptions 设置线程亲和性，但更灵活的方式是在创建 Session 后，通过 pthread_setaffinity_np() 直接绑定工作线程。需要注意的是，亲和性设置必须在线程启动前或启动后立即执行，否则线程可能已经迁移到其他核心。此外，Android 的 cpuset 机制（如 /dev/cpuset/background）可以限制整个进程的 CPU 范围，但粒度较粗，不适合精确控制单个推理线程。

设置方式	粒度	优点	缺点	推荐场景
sched_setaffinity	线程级	精确控制、实时生效	需要 root 或 CAP_SYS_NICE 权限	嵌入式 Linux、Android root 设备
cpuset	进程/线程组级	无需 root、系统级隔离	粒度粗、切换延迟高	Android 应用进程
taskset 命令	进程级	调试方便、无需改代码	无法动态调整	开发调试阶段

风险提示：将推理线程绑定到所有大核并不总是最优。若大核上同时运行了 GPU 驱动线程或 DSP 任务，反而会加剧资源争抢。建议先通过 top -H -p <pid> 观察各核心负载，再决定绑定策略。另外，部分设备（如某些 MTK 平台）的 CPU 核心编号不连续，需通过 /sys/devices/system/cpu/online 确认可用核心列表。

3.4 调度策略：SCHED_OTHER、SCHED_RR 与 SCHED_FIFO

Linux 调度策略分为普通调度（CFS，完全公平调度）和实时调度（RT）。ONNX Runtime 推理线程默认使用 SCHED_OTHER（CFS），由内核根据 nice 值和负载动态分配 CPU 时间。对于延迟敏感型推理任务，可考虑切换到 SCHED_FIFO 或 SCHED_RR，使推理线程获得优先调度权。但实时调度策略需要谨慎使用：若推理线程陷入死循环，将阻塞整个系统；且实时线程不受 CFS 的公平性约束，可能导致其他关键线程（如 UI 渲染）饥饿。

判断是否需要切换调度策略的标准是：延迟抖动是否超过目标值。例如，若推理平均延迟 8ms，但 P99 延迟达到 25ms，且通过 perf sched 分析发现延迟主要来自调度等待，则可尝试将推理线程设为 SCHED_FIFO 并设置优先级 80~90（范围 1~99）。在 Android 上，需使用 android_set_thread_priority() 或 JNI 调用 sched_setscheduler()，且需要 android.permission.RAISE_THREAD_PRIORITY 权限。

// 设置实时调度策略示例（Linux，需 root）
#include <sched.h>
#include <pthread.h>

struct sched_param param;
param.sched_priority = 85;
pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);

  案例拆解：某 AI 盒子设备（RK3588，8 核 A76+A55）运行 YOLOv5s 模型，初始配置为 8 线程、SCHED_OTHER，实测平均延迟 12ms，但 P99 达到 30ms。通过 perf sched record 抓取调度事件，发现推理线程频繁在 A76 和 A55 核心间迁移，且被后台日志服务抢占。优化步骤：① 将线程池设为 4 线程，绑定到 4 颗 A76 大核；② 使用 sched_setscheduler 将推理线程设为 SCHED_FIFO 优先级 80；③ 将日志服务进程绑定到小核。优化后平均延迟 9ms，P99 降至 14ms，抖动减少 53%。代价是系统 UI 响应略有下降，但该设备为无头模式，可接受。

3.5 常见误区与总结复盘

误区一：线程数越多越好。端侧 CPU 核心数有限，且内存带宽成为瓶颈时，多线程反而增加缓存一致性开销。正确做法是先用 perf stat 观察 IPC（每周期指令数），若 IPC 低于 0.5，说明内存受限，应减少线程数。

误区二：亲和性设置后一劳永逸。系统休眠/唤醒、CPU 热插拔（如某些 ARM 平台的核心离线）会导致亲和性设置失效。应在每次推理前检查 sched_getaffinity() 是否仍符合预期。

误区三：实时调度策略万能。SCHED_FIFO 只解决调度优先级问题，不解决锁竞争和 I/O 阻塞。若推理线程内部有互斥锁等待，实时优先级反而可能造成优先级反转（低优先级线程持有锁，高优先级线程等待）。

总结复盘：线程调度优化的核心流程是：先测量（perf sched、trace-cmd）→ 再分析（识别迁移、抢占、锁竞争）→ 后调整（线程数、亲和性、调度策略）→ 最后验证（P99 延迟、功耗）。在 ONNX Runtime 端侧推理中，建议优先调整线程池大小和亲和性，这两项收益最大且风险最低；调度策略调整应作为最后手段，并配合看门狗机制防止实时线程失控。