📚 Linux 中断下半部：机制、并发与演进笔记
一、 中断处理的"两阶段"哲学
Linux 为了平衡硬件响应速度 和系统处理能力，将中断分为两个阶段：
- 上半部（Top Half / Hard IRQ）：
- 特点：执行时间极短，关闭中断，优先级最高。
- 任务：只做最紧急的事（清中断位、存入缓冲区、挂起下半部）。
- 下半部（Bottom Half）：
- 特点：开中断执行，允许耗时操作，优先级次之。
- 任务：处理复杂的业务逻辑（数据解析、唤醒进程等）。
二、 核心机制对比：为什么 Tasklet 正在淡出？
随着 Linux 内核向多核（SMP）和实时化演进，下半部的选型发生了重要变化。
| 机制类型 | 执行上下文 | 允许休眠 | 多核并发性 | 现代评价 |
|---|---|---|---|---|
| Tasklet | 软中断 (原子) | 否 | 差（同类型只能单核运行） | 不推荐。容易引起系统卡顿，扩展性差。 |
| Workqueue | 内核线程 (进程) | 是 | 极好 | 推荐。适合处理逻辑复杂、耗时长的任务。 |
| Threaded IRQ | 内核线程 (进程) | 是 | 极好 | 最推荐。现代驱动标准，优先级可调，代码简洁。 |
💡 关键结论 ：现代内核更倾向于使用带线程的中断（Threaded IRQ） ，因为它能像普通进程一样被调度器管理，甚至可以利用
mutex锁和msleep，极大地提高了驱动的稳定性。
三、 上半部与下半部的"多对一"关系
任务量累积 vs 实例不增加
这是总结出的精髓："中断下半部的任务量会累积，但中断下半部的数量不会增加。"
- 调度去重 ：内核利用"位图（Bitmask）"记录下半部请求。无论上半部触发多少次，位图中对应的
pending位也只是从0变成1。 - 批处理（Batch Processing） ：下半部醒来一次，其使命不是处理"一个"数据，而是通过
while循环处理缓冲区中"所有"累积的数据。
四、 并发与重入处理
1. 如果下半部被上半部打断会怎样？
当 CPU 正在执行下半部时，新的硬件中断依然可以触发上半部：
- 下半部被挂起，CPU 跳转执行上半部。
- 上半部存入新数据，再次"勾选"下半部标志位。
- 上半部退出，CPU 回到刚才被打断的下半部继续运行。
- 下半部完成当前逻辑后，会检查标志位，发现又有新活，于是原地再跑一圈。
2. 为什么不会开两个下半部？
- 防止栈溢出：如果允许嵌套开启，高频中断会迅速耗尽几 KB 的内核栈。
- 简化锁逻辑：保证同一个 CPU 上下半部串行执行，避免了复杂的同步问题。
五、 极端情况：ksoftirqd 救场
如果下半部任务堆积太多（比如网卡每秒万次中断），导致下半部一直"原地转圈"不肯退出，用户进程会饿死（假死机）。
- 退让机制 ：内核会监控软中断执行时间。如果超过阈值，它会强制停止当前软中断，并唤醒内核线程
ksoftirqd。 - 意义 ：
ksoftirqd以进程优先级运行，它让下半部和用户程序公平竞争 CPU，保证系统在极高负载下依然有响应。
六、 驱动开发金律
作为嵌入式开发者（如 i.MX6ULL 平台），编写驱动时必须遵循：
- 下半部回调函数必须带
while循环，直到排空 FIFO 缓冲区。 - 绝对不能在软中断上下文（Tasklet）里睡眠。
- **优先考虑
request_threaded_irq**，让消抖、I2C/SPI 读取等耗时动作在线程里安全运行。