2. Linux内核调度与中断：进程调度策略（CFS、RT）、中断上下文的性能影响、软中断与tasklet
在嵌入式Linux驱动开发中，理解内核的调度机制与中断处理模型是性能优化的基石。驱动代码的执行时机、延迟敏感度以及吞吐量表现，直接受到进程调度策略和中断上下文的制约。本章将深入剖析完全公平调度（CFS）与实时调度（RT）策略、中断上下文的性能开销，以及软中断与tasklet的协作机制。
2.1 进程调度策略：CFS与RT
Linux内核支持多种调度策略，用于决定哪个进程获得CPU使用权。对于驱动开发者而言，最核心的是完全公平调度（CFS）和实时调度（RT）。
2.1.1 完全公平调度（CFS）
CFS是Linux默认的调度策略，其设计目标是让每个进程公平地获得CPU时间。它使用红黑树（Red-Black Tree）来管理可运行进程，以虚拟运行时间（vruntime）作为调度依据。vruntime越小的进程，越优先被调度。
- 核心机制：CFS维护一个红黑树，键值为进程的vruntime。调度器每次选择树最左端的节点（vruntime最小）运行。
- vruntime计算：vruntime = 实际运行时间 × (NICE_0_LOAD / 进程权重)。权重由进程的nice值决定，nice值越低，权重越高，vruntime增长越慢，从而获得更多CPU时间。
- 性能影响：CFS适合非实时、交互式负载。对于驱动中的批量数据处理，CFS能保证整体吞吐量，但无法提供确定性的低延迟。
2.1.2 实时调度（RT）
RT调度策略包括SCHED_FIFO和SCHED_RR，它们为需要严格响应时间的任务设计。RT进程的优先级（0-99，数值越小优先级越高）高于所有CFS进程（nice值映射到100-139优先级）。
| 特性 | SCHED_FIFO | SCHED_RR |
|---|---|---|
| 调度规则 | 先入先出，除非被更高优先级抢占或主动让出CPU，否则一直运行 | 时间片轮转，相同优先级进程轮流获得固定时间片 |
| 适用场景 | 需要独占CPU直到完成的关键任务（如中断处理下半部） | 多个同优先级实时任务需要公平共享CPU |
| 优先级范围 | 0（最高）~ 99（最低） | 0（最高）~ 99（最低） |
| 性能风险 | 优先级反转、死锁、低优先级任务饿死 | 时间片切换开销，但避免了饿死 |
2.1.3 调度策略选择对比
下表总结了不同负载下调度策略的选择建议：
| 负载类型 | 推荐策略 | 延迟特性 | 吞吐量特性 |
|---|---|---|---|
| 批量数据处理（如文件系统、网络栈） | CFS (SCHED_OTHER) | 中等，不可预测 | 高，公平分配 |
| 周期性控制（如电机PID、传感器采样） | SCHED_FIFO | 低，确定性高 | 中等，可能影响其他任务 |
| 多媒体播放（如音频、视频解码） | SCHED_RR 或 CFS + 低nice值 | 低到中等 | 高，需平衡实时性与公平性 |
| 中断处理下半部（如tasklet、workqueue） | 软中断上下文（不可调度）或RT workqueue | 极低（软中断） | 取决于处理逻辑 |
2.2 中断上下文的性能影响
中断处理是驱动与硬件交互的核心方式。中断处理程序（ISR）运行在中断上下文中，该上下文具有严格的限制和性能特征。
2.2.1 中断上下文的特点
- 不可睡眠：中断上下文不能调用可能导致睡眠的函数（如
kmalloc(GFP_KERNEL)、mutex_lock()、copy_to_user()）。 - 不可被抢占：在单核系统中，中断上下文会阻塞其他中断（取决于中断优先级）。在多核系统中，同一中断线通常被屏蔽。
- 栈空间有限：中断栈通常只有4KB或8KB，必须避免深度递归或大局部变量。
- 高优先级：中断上下文优先级高于任何用户态进程，甚至高于RT进程。
2.2.2 中断延迟的来源
中断延迟是指从硬件产生中断信号到ISR开始执行的时间。主要来源包括：
- 中断屏蔽：当CPU正在处理其他中断或执行临界区代码时，新中断被延迟。
- 中断嵌套：高优先级中断抢占低优先级中断的处理。
- 中断处理时间：ISR本身执行时间过长，会阻塞后续中断。
- 缓存未命中：中断上下文切换导致指令和数据缓存失效。
2.2.3 中断上下文的性能优化原则
| 优化方向 | 具体措施 | 效果 |
|---|---|---|
| 减少ISR执行时间 | ISR只做最少的必要操作（如读取硬件状态、清除中断标志），将复杂处理推迟到下半部 | 降低中断屏蔽时间，减少延迟 |
| 使用中断线程化 | 通过request_threaded_irq()将ISR主体放到内核线程中执行 |
允许睡眠、可被调度，降低对实时性的冲击 |
| 合理设置中断亲和性 | 将中断绑定到特定CPU核心，避免跨核迁移 | 提高缓存命中率，减少延迟抖动 |
| 使用MSI/MSI-X | 对于PCIe设备，使用消息信号中断代替传统引脚中断 | 减少中断向量共享，提高分发效率 |
2.3 软中断与tasklet
为了减少中断屏蔽时间，Linux将中断处理分为上半部（Top Half）和下半部（Bottom Half）。上半部是ISR本身，下半部则在中断使能后执行。软中断和tasklet是两种经典的下半部机制。
2.3.1 软中断（SoftIRQ）
软中断是内核预定义的一组静态下半部机制，在__do_softirq()中执行。它们运行在软中断上下文中，可以响应中断，但不能睡眠。
- 特性：软中断在多个CPU上可以并行执行（同一类型的软中断除外）。
- 常见类型：
NET_TX_SOFTIRQ（网络发送）、NET_RX_SOFTIRQ（网络接收）、TASKLET_SOFTIRQ（tasklet调度）、RCU_SOFTIRQ等。 - 性能优势：软中断执行优先级高，延迟低，适合对吞吐量要求极高的场景（如网络数据包处理）。
- 性能风险：如果软中断执行时间过长，会导致用户态进程饥饿，且可能触发
ksoftirqd内核线程接管，增加调度开销。
2.3.2 tasklet
tasklet是基于软中断实现的一种动态下半部机制。它比直接使用软中断更简单，但灵活性稍差。
- 特性：tasklet在同一时刻只能在一个CPU上执行，且同一类型的tasklet串行执行。
- 使用方式：通过
DECLARE_TASKLET()或tasklet_init()创建，使用tasklet_schedule()调度。 - 性能对比：tasklet的串行特性避免了并发竞争，但降低了多核扩展性。对于单核或低并发场景，tasklet足够高效。
2.3.3 软中断与tasklet的对比
| 特性 | 软中断（SoftIRQ） | tasklet |
|---|---|---|
| 并发性 | 同一类型软中断在多个CPU上串行，不同类型可并行 | 同一tasklet在多个CPU上串行，不同tasklet可并行 |
| 动态性 | 静态分配，编译时定义 | 动态创建和销毁 |
| 使用复杂度 | 较高，需要注册软中断处理函数 | 较低，API简单 |
| 执行上下文 | 软中断上下文（可响应中断，不可睡眠） | 软中断上下文（可响应中断，不可睡眠） |
| 典型应用 | 网络协议栈、块设备层 | 简单字符设备、GPIO中断处理 |
| 多核扩展性 | 优秀 | 一般 |
2.3.4 下半部选择决策树
在驱动开发中，选择正确的下半部机制至关重要。以下决策树可帮助选择：
- 处理是否需要睡眠？
- 是 → 使用workqueue（或中断线程化）
- 否 → 进入下一步
- 是否需要多核并行处理？
- 是 → 使用软中断（如网络驱动）
- 否 → 进入下一步
- 是否需要动态创建/销毁？
- 是 → 使用tasklet（或workqueue）
- 否 → 使用tasklet（简单场景）或软中断（高性能场景）
2.4 中断与调度对驱动性能的综合影响
驱动性能优化需要综合考虑调度策略和中断处理。以下是一个典型的性能分析案例：
问题：UART接收中断频繁，ISR中直接进行字符处理，导致高优先级中断阻塞其他任务，且用户态读取延迟大。
优化方案：
1. ISR中只读取FIFO数据并放入环形缓冲区，清除中断标志。
2. 使用tasklet（或workqueue）处理数据解析和协议栈交互。
3. 将用户态读取线程设置为SCHED_FIFO优先级50，确保数据及时被消费。
结果：中断延迟从15µs降至3µs，吞吐量提升40%，用户态读取延迟抖动从200µs降至20µs。