任务切换开销量化：保存/恢复寄存器周期数、栈操作时间、Cache/TLB影响、测量方法
任务切换到底要花多少时间？这个问题，我几乎在每个项目里都会被问到。很多人觉得不就是保存几个寄存器、换个栈指针嘛，能有多慢？
嗯，如果你真这么想，那说明你还没被坑过。我见过一个产品，就因为任务切换开销没算准，导致中断响应超时，整批货差点返工。今天咱们就把这笔账算清楚。
一、任务切换开销的构成
说白了，一次任务切换就是「把当前任务的状态存起来，再把下一个任务的状态恢复出来」。这中间涉及三个大头：
- 寄存器保存/恢复：CPU 通用寄存器、状态寄存器、浮点寄存器等
- 栈操作：压栈、弹栈、栈指针调整
- Cache/TLB 影响：切换后缓存失效，重新加载
我习惯把这三部分分开测量，因为它们的量级完全不同。寄存器操作是确定的，栈操作跟任务栈深度有关，Cache 影响则看你的任务内存布局。
二、寄存器保存/恢复周期数
这是最「硬」的部分。以 ARM Cortex-M4 为例，一次 PendSV 异常处理中，硬件自动压栈 8 个寄存器（R0-R3、R12、LR、PC、xPSR），软件再手动压栈剩余的 R4-R11。总共 16 个寄存器，每个寄存器压栈/弹栈各 1 个周期。
| 操作 | 寄存器数量 | 单次周期 | 总周期数 |
|---|---|---|---|
| 硬件自动压栈 | 8 | 1 | 8 |
| 软件手动压栈 | 8 | 1 | 8 |
| 软件手动弹栈 | 8 | 1 | 8 |
| 硬件自动弹栈 | 8 | 1 | 8 |
| 合计 | 32 |
你看，纯寄存器操作才 32 个周期。在 100MHz 的 MCU 上，这就是 0.32 微秒。但实际测量结果往往比这个高得多，为什么？
关键点：寄存器操作只是冰山一角。真正的开销在栈操作和 Cache 影响上。
三、栈操作时间
每个任务都有自己的栈空间。切换时，当前任务的栈指针要保存，新任务的栈指针要加载。这本身很快，但问题出在栈的「位置」上。
我曾经在一个项目里，把两个任务的栈分配到了不同的内存区域。一个在 SRAM 的起始地址，一个在末尾。结果每次切换，CPU 都要跨越整个 SRAM 去访问栈，内存访问延迟直接翻倍。
栈操作时间可以用这个公式估算：
栈操作时间 = (压栈字节数 + 弹栈字节数) × 单字节访问周期举个例子，如果每个任务栈深度 256 字节，切换时全部保存/恢复，那就是 512 字节的读写。在 72MHz 的 STM32F1 上，单字节访问约 2 个周期，总共 1024 个周期，约 14 微秒。这已经比寄存器操作大了两个数量级。
我的建议：任务栈不要全量保存。很多 RTOS 只保存当前用到的寄存器，栈内容由任务自己管理。除非你用的是「完全上下文切换」模式。
四、Cache/TLB 影响
这部分最容易被忽略，但影响最大。如果你的 MCU 带 Cache（比如 Cortex-M7 或更高端系列），任务切换后，新任务的代码和数据很可能不在 Cache 里。
我遇到过最夸张的一次：一个任务切换后，第一条指令就 Cache Miss，然后触发了一次完整的 Cache Line Fill，花了 20 多个周期。紧接着第二条指令又 Miss，再花 20 个周期。连续 10 条指令 Miss，200 个周期就没了。
TLB 的影响类似。如果任务使用了不同的虚拟地址空间（比如带 MPU/MMU 的场景），切换后 TLB 全部失效，每次内存访问都要重新查页表。
| 场景 | 无 Cache | 有 Cache（命中） | 有 Cache（Miss） |
|---|---|---|---|
| 寄存器操作 | 32 周期 | 32 周期 | 32 周期 |
| 栈操作（256B） | 1024 周期 | 128 周期 | 2048 周期 |
| 指令执行 | 正常 | 正常 | 20-50 周期/条 |
避坑指南：我曾经在一个带 Cache 的项目里，任务切换后频繁 Cache Miss，导致调度延迟从预期的 5 微秒飙升到 50 微秒。排查了两天才发现是任务代码段没有做 Cache 对齐。后来我把每个任务的代码段都按 Cache Line 对齐，Miss 率降了 70%。
五、测量方法
理论算完了，咱们得动手测。我常用的方法有三种：
方法一：GPIO 示波器法
这是最土但最可靠的方法。在任务切换的入口和出口各拉一次 GPIO，用示波器量脉冲宽度。
// 伪代码示例
void PendSV_Handler(void) {
GPIO_SetPin(HIGH); // 开始切换
// 保存当前任务寄存器
// 加载新任务寄存器
GPIO_SetPin(LOW); // 切换结束
}示波器上看到的脉冲宽度，就是一次任务切换的总时间。我习惯测 100 次取平均，排除单次抖动。
方法二：硬件计数器法
很多 MCU 有 DWT（Data Watchpoint and Trace）单元，里面有个 CYCCNT 寄存器，可以精确计数 CPU 周期。
uint32_t start, end;
start = DWT->CYCCNT;
// 执行任务切换
end = DWT->CYCCNT;
uint32_t cycles = end - start;这个方法精度高，但要注意 CYCCNT 溢出。我一般测短时间内的切换，确保不溢出。
方法三：RTOS 内置统计
像 FreeRTOS 这种成熟的 RTOS，有内置的任务切换时间统计功能。打开 configGENERATE_RUN_TIME_STATS 宏，就能拿到每个任务的运行时间和切换次数。
实战经验：三种方法我建议都做一遍。GPIO 法看宏观，计数器法看微观，RTOS 统计看整体。三组数据对比，才能定位真正的瓶颈。
六、知识结构图
下面这张图总结了任务切换开销的构成和测量方法，方便你对照排查：
七、实战排查清单
最后，我整理了一份排查清单。每次遇到调度延迟问题，我都会按这个顺序查一遍：
- 寄存器操作：确认是否保存了不必要的寄存器（比如浮点寄存器）
- 栈深度：检查任务栈是否过大，是否有栈溢出
- 内存布局：任务栈是否分散在不同内存区域？能否集中？
- Cache 对齐：任务代码段是否按 Cache Line 对齐？
- TLB 刷新：是否每次切换都刷新 TLB？能否用 ASID 避免？
- 测量验证：用 GPIO 法实测，对比理论值，找出偏差
一个小技巧：我习惯在任务切换的代码里加一个「看门狗喂狗」操作。如果切换时间超过预期，看门狗会复位，这样能第一时间发现问题。
任务切换开销，说白了就是「存旧换新」的成本。寄存器操作是固定的，栈操作看你的任务设计，Cache 影响看你的内存布局。把这三笔账算清楚，调度延迟问题就解决了一半。