本文概述：Linux中断分为顶半部和底半部，核心原因是顶半部运行在中断上下文，不能被打断，必须快速执行完返回，否则会影响系统响应能力甚至丢失中断。顶半部只做最紧急的事：确认中断、保存现场、登记底半部。底半部做耗时的处理，可以被打断。常见底半部机制有三种：tasklet（软中断上下文、不能睡眠）、工作队列（进程上下文、可以睡眠）、threaded_irq（内核线程、支持睡眠）。

核心要点速览

  • 顶半部：快速响应，只做最必要的事，不能睡眠

  • 底半部：处理耗时工作，可以被新中断打断

  • tasklet：基于软中断，原子上下文，不能阻塞

  • workqueue：内核线程，进程上下文，可以睡眠

  • threaded_irq：将中断处理全部放在线程中执行

面试题

面试官问：Linux的中断处理为什么要分顶半部和底半部？两者有什么区别？你常用哪种底半部机制？

面试官考察点

  1. 是否真正理解中断上下文的特性和限制

  2. 是否清楚顶半部和底半部各自的职责边界

  3. 是否了解多种底半部机制及其适用场景

  4. 是否有实际驱动开发和中断调试经验

  5. 是否理解中断响应延迟和系统性能的权衡

回答思路

第一，为什么要分顶半部和底半部

这要从中断处理的特点说起。中断处理函数运行在中断上下文，它的特点是：

  • 不可抢占，执行过程中不能被调度

  • 同一中断线的后续中断会被屏蔽或延迟

  • 不能睡眠，因为睡眠需要调度，而中断上下文不能被调度出去

如果中断处理函数执行时间太长，会带来几个问题：一是系统响应延迟变大，其他中断得不到及时处理；二是可能导致中断丢失，因为中断排队深度有限；三是影响系统整体实时性。

所以Linux把中断处理分成两部分：顶半部做最紧急、最快速的事，比如清中断标志、保存必要数据、触发底半部，然后就返回；底半部做剩下的耗时工作，可以被打断，也可以调度。

第二，顶半部和底半部的区别

对比项顶半部底半部
执行上下文中断上下文软中断上下文 / 进程上下文
能否被调度不能，不可抢占部分可以（如workqueue）
能否睡眠绝对不能tasklet不能，workqueue可以
执行时机中断立即触发稍后某个合适的时机
负责工作快速、紧急的操作耗时的数据处理
时间要求越短越好，微秒级相对宽松，毫秒级可接受

第三，常见底半部机制对比

tasklet（小任务）：基于软中断实现，运行在软中断上下文。特点是执行速度快、延迟低，但不能睡眠，不能做耗时很长的操作。适合中断处理中那些不紧急但又不能睡眠的处理，比如网络数据包的协议解析、输入事件的处理等。同一tasklet不会在多个CPU上同时运行，有串行化保证。

工作队列（workqueue）：运行在内核线程中，属于进程上下文。特点是可以睡眠、可以阻塞、可以调用可能导致调度的函数。适合需要睡眠的场景，比如需要读写寄存器配合延时、需要分配大量内存、需要和用户空间交互等。缺点是延迟比tasklet大，因为涉及进程调度。

threaded_irq（线程化中断）：是一种特殊的中断处理方式，把中断处理全部放在内核线程中执行。顶半部只有简单的唤醒操作，真正的处理在中断线程里。适合中断处理本身就比较复杂、需要睡眠的场景。使用简单，request_threaded_irq直接注册。

第四，选型原则

怎么选择用哪种底半部机制，可以按以下思路判断：

  • 处理逻辑简单、很快、不需要睡眠 → 直接在顶半部完成，不用底半部

  • 稍复杂但还是很快、不需要睡眠 → 用tasklet

  • 需要睡眠、需要调用阻塞函数 → 用workqueue

  • 整个中断处理都比较重、希望简化设计 → 用threaded_irq

实际驱动开发中，用workqueue和threaded_irq的情况越来越多，因为现代处理器性能足够，额外的调度延迟影响不大，但编程更简单、不容易出bug。

第五，实际开发中的注意事项

第一，顶半部里绝对不能调用可能导致睡眠的函数，比如msleep、kmalloc(GFP_KERNEL)、copy_from_user等。否则会触发内核警告甚至panic。

第二，底半部和顶半部之间的数据传递要考虑并发安全，用自旋锁或原子操作保护。

第三，tasklet不能保证执行的精确延迟，如果对延迟敏感，要评估最坏情况。

第四，workqueue有系统共享的和自定义的两种。如果处理耗时较长，建议创建自己的工作队列线程，避免影响系统其他工作。

第五，调试中断问题时，要注意是否有中断风暴（interrupt storm）的情况，就是底半部处理慢导致中断大量堆积。

常见追问

  1. 软中断和tasklet是什么关系？有什么区别？

  2. workqueue和内核线程有什么区别和联系？

  3. 中断上下文为什么不能睡眠？如果睡眠了会怎样？

  4. threaded_irq和普通中断+workqueue有什么区别？

  5. 共享中断的顶半部和底半部设计要注意什么？

失分表达

避免这样说：

  • "底半部就是延后执行，没什么特别的"——不理解上下文差异

  • "tasklet和workqueue差不多，随便用"——不知道睡眠限制的区别

  • "中断里调msleep没关系吧"——不知道中断上下文不能睡眠

准备动作

  1. 理解中断上下文和进程上下文的本质区别

  2. 记住三种底半部机制的特点、适用场景和API

  3. 准备一个自己写过的驱动中断处理作为案例

  4. 了解软中断的工作机制和ksoftirqd内核线程

  5. 知道中断风暴的现象、原因和排查方法

核心关键词

Linux中断处理、顶半部底半部、tasklet、工作队列workqueue、threaded_irq、中断上下文、软中断、进程上下文、中断延迟、中断风暴

FAQ常见问题

Q1: 什么是中断上下文？和进程上下文有什么区别？
中断上下文是指CPU正在处理中断时的运行环境。它不属于任何进程，没有对应的task_struct，不能被调度器调度。而进程上下文是某个进程运行时的环境，有完整的进程描述符，可以被调度和睡眠。
Q2: 底半部执行的时机是什么时候？
软中断类的底半部（tasklet）在顶半部返回后、中断退出前的软中断检查点执行，也可能由ksoftirqd内核线程执行（软中断太多时）。工作队列则由内核工作线程在调度时机执行。
Q3: 为什么不能在中断里睡眠？
睡眠需要调用调度器，把当前进程挂起。但中断上下文没有对应的进程实体，调度器无法"调度回来"，因为中断上下文不属于任何进程，scheduler不知道该怎么恢复它。所以在中断上下文睡眠会导致内核状态混乱。