3. 抢占延迟模型：拆解延迟的每一毫秒

各位同学，今天我们来聊聊抢占延迟模型。说实话，这个模型是实时系统里最容易被低估的东西。很多人觉得抢占嘛，不就是停下一个任务，换另一个上吗？哪有那么简单。

我当年第一次做GPU抢占优化时，就被现实狠狠教育了一回。系统明明设计好了优先级，结果高优先级任务还是等了好久才拿到GPU。后来一查，问题全出在抢占延迟上。所以今天，咱们就把这个延迟拆开来看。

3.1 抢占延迟的三大组成部分

抢占延迟，说白了就是从你决定抢占，到新任务真正开始跑，中间浪费掉的时间。我习惯把它分成三段：检测延迟、保存延迟、恢复延迟。

3.1.1 检测延迟

检测延迟是什么？就是系统发现「嘿，有个高优先级任务来了」所需要的时间。

你想想看，GPU正在埋头苦干，执行着低优先级任务。这时候高优先级任务来了，它得先通知GPU吧？这个通知过程，就是检测延迟。

我在项目中遇到过一种情况：GPU的调度器是轮询检查的，每1ms才看一次有没有新任务。结果高优先级任务来了，最多要等1ms才能被发现。嗯，1ms在实时系统里，已经够跑很多指令了。

3.1.2 保存延迟

检测到抢占请求后，GPU得把当前任务的「现场」保存下来。这个现场包括：寄存器状态、缓存内容、显存中的中间数据等等。

保存延迟有多长？取决于你要保存多少东西。

我曾经调试过一个自动驾驶的GPU系统，低优先级任务正在做图像预处理，突然要抢占去做紧急障碍物检测。结果保存延迟占了整整2ms——因为那个任务把整个显存都占满了，光保存数据就花了很长时间。

3.1.3 恢复延迟

保存完旧任务，就该恢复新任务了。恢复延迟就是把高优先级任务的上下文重新加载到GPU里的时间。

这里有个坑：恢复延迟不仅取决于新任务本身，还取决于它上次被抢占时保存的状态。如果新任务之前也被抢占过，那恢复时得加载两套上下文——自己的和中间状态的。

说白了，恢复延迟就是「把东西从内存搬回GPU」的时间。内存带宽越高，恢复越快。但如果你同时有多个任务在抢占，恢复延迟会叠加。

延迟类型	典型范围	主要影响因素
检测延迟	10μs - 1ms	轮询间隔、中断响应速度
保存延迟	100μs - 5ms	任务上下文大小、显存带宽
恢复延迟	100μs - 3ms	任务上下文大小、内存带宽

3.2 影响抢占延迟的关键因素

知道了延迟的组成，我们来看看哪些因素会影响这些延迟。我总结了三个核心因素：任务大小、优先级、内存带宽。

3.2.1 任务大小

任务大小直接影响保存和恢复延迟。为什么？因为保存和恢复的本质就是数据搬运。

一个任务如果只用了几个寄存器，保存延迟可能只有几十微秒。但如果它占用了大量显存，比如做视频编码的任务，那保存延迟可能飙升到毫秒级。

我记得有个项目，客户抱怨GPU抢占太慢。一查，低优先级任务是个深度学习推理任务，占用了2GB显存。每次抢占都要保存这2GB数据，不慢才怪。

3.2.2 优先级

优先级本身不直接产生延迟，但它决定了抢占策略。

高优先级任务抢占低优先级任务时，系统可能采用不同的处理方式：

• 立即抢占：高优先级任务来了，立刻停掉当前任务。检测延迟最短，但保存延迟可能变长（因为任务可能正在执行关键操作）。
• 延迟抢占：等到当前任务执行到安全点再抢占。检测延迟变长，但保存延迟可控。

你想想看，优先级越高，系统越倾向于立即抢占。但立即抢占带来的保存延迟，有时候反而让总延迟更大。所以优先级设计不是越高越好，得平衡。

3.2.3 内存带宽

内存带宽是硬件层面的硬约束。保存和恢复延迟，说白了就是「数据量 ÷ 带宽」。

举个例子：

假设任务上下文大小 = 1MB
内存带宽 = 10GB/s
保存延迟 = 1MB / 10GB/s = 0.1ms

如果内存带宽降到 5GB/s
保存延迟 = 1MB / 5GB/s = 0.2ms

带宽翻倍，延迟减半。这个道理很简单，但实际系统中带宽是共享的。GPU在跑任务时，内存带宽可能已经被占用了很大一部分。

我遇到过最极端的情况：GPU在做大规模矩阵运算，内存带宽被吃到95%。这时候来个抢占，保存数据的速度慢得像蜗牛。所以我现在做系统设计时，都会预留20%-30%的内存带宽给抢占操作。

好了，这一章的内容就到这里。下一章我们会深入讨论如何测量这些延迟，以及怎么优化它们。记住，理解延迟的组成，是控制它的第一步。