4、CPU负载均衡：多线程渲染、任务调度、CPU亲和性、中断负载均衡

好，咱们进入第四个实战章节。CPU负载均衡，这词儿听起来有点抽象，但说白了就是——别让一个核累死，其他核闲死。

我在做机顶盒项目时，遇到过最典型的情况：UI操作卡成PPT，一查CPU占用率，Core 0已经100%了，Core 1、Core 2还在那打盹儿。你说气不气人？这就是典型的负载不均。今天咱们就把这个问题彻底掰开揉碎。

4.1 多线程渲染：别让主线程扛所有活

机顶盒的图形显示，核心就是渲染管线。传统的做法是：主线程既处理用户输入，又处理网络事件，还得负责把每一帧画面画出来。结果就是——任何一个环节卡一下，整个UI就跟着抖。

我个人习惯，把渲染拆成三个独立线程：

  • UI线程：只处理用户交互和状态更新，不碰任何绘图API
  • 渲染线程：专门负责OpenGL ES或DirectFB的绘制调用
  • 合成线程：把多个图层（视频层、UI层、字幕层）合成最终输出

你想想看，这样一拆，就算渲染线程因为某个复杂特效卡了一帧，UI线程照样能响应用户的按键操作。用户体验就不会有那种「死机感」。

核心原则：渲染管线中的每一级，都应该有自己的线程。线程之间用无锁队列或环形缓冲区通信，避免互斥锁带来的优先级反转。

// 伪代码：渲染线程与合成线程的通信
struct FrameBuffer {
    int width, height;
    void* pixels;
    bool ready;
};

// 无锁环形缓冲区
RingBuffer<FrameBuffer, 4> render_queue;

// 渲染线程
void render_thread() {
    while (running) {
        FrameBuffer fb = render_next_frame();
        render_queue.push(fb);  // 非阻塞写入
    }
}

// 合成线程
void composite_thread() {
    while (running) {
        FrameBuffer fb;
        if (render_queue.pop(&fb)) {  // 非阻塞读取
            composite_to_display(fb);
        }
    }
}

避坑指南：我曾经在项目里用std::mutex保护渲染队列，结果高负载下渲染线程被合成线程阻塞，导致帧率直接腰斩。后来换成无锁队列，问题瞬间解决。记住：渲染管线里，锁就是性能杀手。

4.2 任务调度：谁该跑在哪个核上？

多线程有了，但线程跑在哪个CPU核上，这事儿默认是交给Linux内核的CFS调度器去管的。但CFS调度器是通用调度器，它不知道你的渲染线程有多紧急。

嗯，这里要注意：机顶盒场景下，渲染线程的优先级应该高于后台下载线程。我建议用两种手段配合：

  • SCHED_FIFO实时调度策略：给渲染线程设置实时优先级，确保它被调度时不会被普通线程抢占
  • cgroup限制：把后台任务（日志、OTA下载）限制在低优先级CPU组里
// 设置渲染线程为实时调度
#include <sched.h>

void set_realtime_priority(pthread_t thread, int priority) {
    struct sched_param param;
    param.sched_priority = priority;
    
    int ret = pthread_setschedparam(thread, SCHED_FIFO, &param);
    if (ret != 0) {
        // 需要CAP_SYS_NICE权限，嵌入式系统通常默认有
        perror("pthread_setschedparam failed");
    }
}

// 使用示例
pthread_t render_tid;
pthread_create(&render_tid, NULL, render_thread, NULL);
set_realtime_priority(render_tid, 80);  // 优先级范围0-99，80算较高

警告：实时优先级不是越高越好。我曾经把渲染线程设成99（最高优先级），结果它把中断处理线程都抢占了，导致网络包大量丢包。建议渲染线程设70-85之间，留一些余量给中断处理。

4.3 CPU亲和性：把线程绑定到指定核

任务调度解决了「谁先跑」的问题，但没解决「在哪个核上跑」的问题。CPU亲和性（affinity）就是干这个的。

为什么需要绑定？因为CPU缓存。如果一个线程频繁在不同核之间迁移，L1/L2缓存会反复失效，性能损失可能高达30%。

我在项目中习惯这样分配：

CPU核 绑定的线程 原因
Core 0 中断处理 + 系统服务 中断亲和性通常默认在Core 0，不动它
Core 1 UI线程 + 输入处理 用户交互需要低延迟，独占一个核
Core 2 渲染线程 渲染是计算密集型，独占一个核
Core 3 合成线程 + 后台任务 合成线程与渲染线程共享数据，放一起减少缓存失效 
// 设置CPU亲和性
#define _GNU_SOURCE
#include <sched.h>

void bind_to_core(pthread_t thread, int core_id) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(core_id, &cpuset);
    
    int ret = pthread_setaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
    if (ret != 0) {
        perror("pthread_setaffinity_np failed");
    }
}

// 使用
bind_to_core(render_tid, 2);  // 渲染线程绑定到Core 2

小技巧：可以用taskset命令在启动时直接绑定进程。比如：taskset -c 2 ./render_app。但运行时动态绑定更灵活，我一般两种都用，启动时用taskset兜底，运行时再精细调整。

4.4 中断负载均衡：别让一个核处理所有中断

最后这个点，很多人容易忽略。机顶盒里中断源特别多：HDMI热插拔、红外遥控、网络包、USB设备……默认情况下，所有中断都往Core 0上涌。

你想想看，Core 0本来就要处理系统调度，再来一堆中断，它不卡谁卡？

解决方案是IRQ affinity（中断亲和性）。把不同类型的中断分散到不同核上。

# 查看当前中断分布
cat /proc/interrupts

# 设置某个中断的亲和性（以IRQ 67为例）
echo 2 > /proc/irq/67/smp_affinity  # 二进制10，表示Core 1

# 或者用十六进制
echo 0x04 > /proc/irq/67/smp_affinity  # Core 2

我在项目中遇到过一个问题：红外遥控中断和网络中断都绑在Core 0上，结果用户按遥控器时，网络吞吐量瞬间掉到零。后来把红外中断绑到Core 1，网络中断绑到Core 2，问题解决。

经验总结：中断负载均衡的黄金法则是——高频中断（如网络、定时器）分散到不同核，低频中断（如按键、热插拔）可以集中到某个空闲核。别把所有中断都丢给Core 0。

4.5 实战检查清单

好，讲了这么多，最后给个检查清单。你在调优时，按这个顺序排查：

  1. 检查线程分布：用ps -eLo pid,tid,psr,comm看每个线程跑在哪个核上
  2. 检查中断分布：用cat /proc/interrupts看中断是否均匀
  3. 检查CPU占用率：用mpstat -P ALL 1看每个核的负载是否均衡
  4. 检查缓存命中率：用perf stat -e cache-misses看线程迁移导致的缓存失效

我曾经在一个项目里，做完前三步发现负载已经很均衡了，但帧率还是上不去。最后用perf一查，发现渲染线程每秒钟在Core 2和Core 3之间迁移了上千次，缓存命中率只有40%。加上亲和性绑定后，缓存命中率升到85%，帧率直接翻倍。

嗯，CPU负载均衡这事儿，说白了就是「让每个核干它最擅长的事」。别让Core 0当救火队员，也别让Core 3在那摸鱼。把线程、中断、缓存都安排明白了，你的机顶盒图形显示系统，才能真正跑出硬件的全部潜力。

← 上一章 📖 返回目录 下一章 →