中断与定时器
这页讲的是：很多事情不会等程序慢慢轮询再处理，硬件事件会突然发生，时间也会持续推进，所以 Linux 需要一套机制来处理“外部打断”和“按时间触发”的系统行为。
这块是什么
中断与定时器是内核响应外部事件和时间推进的基础机制。网卡收到包、磁盘完成 I/O、键盘有输入，这些都可能通过中断通知内核；而任务超时、调度节拍、延后执行等，又需要定时器帮助系统“按时间办事”。
可以把中断理解成“外部有人突然敲门”，把定时器理解成“系统自己设好的闹钟”。
它负责什么
响应外部事件
- 接收硬件发来的中断信号
- 尽快让内核知道设备有事发生
- 减少无意义轮询
- 让系统更及时地响应真实世界变化
推动时间相关行为
- 超时处理
- 延后执行
- 周期性任务推进
- 帮助系统把“时间到了该做什么”落地
衔接更长路径的后续处理
- 快速确认事件发生
- 把重活交给后续上下文处理
- 配合软中断、workqueue 等机制
- 避免在最敏感的时刻做太多事
为什么不能所有事都直接在中断里做完
| 原因 | 你现在怎么理解 |
|---|
| 中断上下文约束很强 | 它更像“紧急插队”，不是适合慢慢干活的普通工作环境。 |
| 系统需要快速恢复正常执行 | 如果中断里做太久，别的任务和别的中断都会受影响。 |
| 很多后续工作更适合普通上下文 | 例如较重的数据处理、等待资源、异步清理等，通常要下放到后续路径。 |
| 性能和延迟都要兼顾 | 中断不是越多做越好，而是应该尽快确认事件并安排后续处理。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| 中断 | 硬件或系统事件用来打断当前执行流、提醒内核“现在有事要处理”的机制。 |
| 中断处理程序 | 接到中断后最先执行的那段响应逻辑，通常应尽量短。 |
| 软中断 / 下半部 | 把部分工作延后到更合适上下文里做的思路。 |
| 定时器 | 在未来某个时间点触发某段处理逻辑的机制。 |
| 时钟节拍 | 帮助系统感知时间推进、驱动某些周期性行为的基础节奏。 |
为什么重要
- 没有中断，系统就要不停轮询硬件，效率和响应都会很差。
- 没有定时器，很多超时、延后和调度推进机制就无从谈起。
- 很多网络、存储、输入设备路径，本质上都建立在“事件触发 + 后续处理”模式上。
- 它同时深刻影响系统延迟、吞吐和并发模型。
常见误解
- 误解一：中断就是“收到事件然后马上做完全部工作”。实际上很多路径都会把重活拆到后续上下文。
- 误解二：定时器只是小工具。实际上它支撑着大量系统级时间行为。
- 误解三：这是驱动才关心的东西。实际上调度、网络、存储、超时控制都会依赖它。
它不负责什么
- 它不定义文件或网络语义，但这些子系统大量依赖它来接收事件。
- 它不替代调度器，但调度器会依赖时间推进和事件触发。
- 它不单独解决并发问题，但会显著增加并发和上下文切换复杂度。
和其他模块的关系
| 相关模块 | 关系 |
|---|
| 驱动 | 很多驱动通过中断知道设备完成了某件事。 |
| 调度器 | 时间推进和事件触发会影响调度时机与系统响应。 |
| 并发控制 | 中断上下文限制很强，直接影响同步方式选择。 |
| 网络 / 存储 | 收包、完成 I/O 等关键路径都深受中断和延后处理机制影响。 |
一条典型事件路径现在可以怎么想
| 步骤 | 发生了什么 | 你先抓哪层意思 |
|---|
| 设备发来事件 | 硬件先通过中断把“有事发生”这件事通知内核。 | 中断首先解决的是通知，不是把全部工作做完。 |
| 前线快速确认 | 中断处理程序尽快确认来源、做最少必要动作。 | 最前线强调短、快、不能拖。 |
| 后续工作延后 | 较重的数据处理、唤醒、清理等被交给别的上下文。 | 这一步才是很多子系统真正开始干活的地方。 |
| 时间机制继续推动 | 超时、延迟和周期性行为再由定时器一类机制往前推。 | 系统不只响应“外面发生了什么”，也要处理“时间到了什么该发生”。 |
读完这页后，你应该能回答
- 为什么内核需要中断，而不是一直轮询？
- 为什么很多事情不能直接在中断处理程序里做完？
- 为什么定时器不只是“闹钟”，而是系统时间行为的重要基础？
后面适合继续问：软中断和 workqueue 的关系是什么？为什么中断上下文里限制这么多？时钟节拍和调度之间是什么关系？