Linux中断处理机制解析：顶半部与底半部设计及选型实践

你有没有遇到过这样的场景：一个网络小包到达网卡，CPU 被中断打断，在中断处理函数里跑了几十微秒，结果整个系统的实时任务被卡得死死的；或者一个 GPIO 按键按下，中断里做了太多事，导致其它中断被长期延迟，系统看起来就是"卡"了一下。

中断处理是 Linux 内核里绕不开的话题。只要是做嵌入式、驱动开发、性能调优，或者面试 Linux 内核岗位，都会碰到它。而中断处理里最核心的设计之一，就是顶半部（top half） 和底半部（bottom half） 的拆分机制。把一次中断处理切成两段，前者快速响应硬件、后者延迟处理重活，这套思路本质上解决的是"CPU 不能长时间关中断"这个硬约束。

这篇文章我从实际项目视角出发，把顶半部和底半部怎么做、为什么这么做、有哪些坑、如何选型一次讲清楚。内容偏实践，不适合只想背概念应付面试的人，适合真正要去写驱动、调性能、排查线上问题的朋友。

1. 一次中断请求的完整旅程：先建立整体认知

1.1 中断上下文不是什么都能干

在讲顶半部和底半部之前，得先理解中断处理函数运行在什么环境下。当硬件触发中断后，CPU 会跳转到内核预先注册的中断处理函数，也就是 ISR（Interrupt Service Routine）。这个 ISR 跑在中断上下文里，它和普通进程上下文有几个本质区别。

进程上下文拥有自己的 task_struct、mm_struct、用户栈；而中断上下文是"借"当前被打断进程的上下文。如果你在 ISR 里调用可能睡眠的函数，比如 mutex_lock、msleep、wait_event，内核会直接报错，严重时直接 oops。根本原因是：睡眠需要调度器介入，而调度器本身依赖进程的概念，中断上下文里没有可调度的进程实体。说得直白点，系统根本不知道"该让谁去睡"。

第二个限制是栈空间。内核栈在 x86 上是 4KB 或 8KB，arm64 有 16KB 的 THREAD_INFO 设置。ISR 一旦嵌套或者用递归、大数组，很容易把栈打爆。这类问题极其难排查，往往表现为随机的 stack overflow panic。

第三个限制是不能被自己的同类型中断打断。中断处理期间，本地 CPU 屏蔽了同一条中断线的再次触发（具体取决于中断控制器和内核设置），如果 ISR 跑得慢，后续中断只能排队等着。你写了一个耗时 100 微秒的中断处理函数，那就意味着这段期间同设备后续事件全部延迟 100 微秒以上。

有了这三点约束，你就能理解为什么内核要把中断处理拆成两段：一段快进快出、一段慢工细活。

1.2 为什么要拆分：拿"快速响应"换"系统稳定"

顶半部和底半部的设计思路，本质上是在做时间换空间、速度换稳定的策略妥协。硬件中断来了，你必须尽快响应，因为外设的 FIFO 可能只有几百字节，数据不取走就会被覆盖。所以顶半部的职责非常明确：把该抢救的数据抢救下来，把硬件状态确认掉，然后通知内核"后面还有事要处理"，立即返回。

底半部则相对从容。它在稍晚的时机执行，可以忍受延迟，可以有更多时间做数据处理、协议解析、唤醒用户进程等操作。这样设计的好处有两个：

第一，缩短关中断时间，降低系统中断延迟。Linux 是通用操作系统，很多场景对实时性有要求，顶半部短小精悍，系统的响应上限会高很多。

第二，给"重活"找到合理的上下文环境。底半部的实现方式有好几种，有的仍然跑在中断上下文（softirq、tasklet），有的已经跑在进程上下文（workqueue、threaded irq）。跑到进程上下文里意味着可以睡眠、可以被抢占、可以使用大部分内核 API，但这也会带来延迟上的代价。

我从一个实际例子说起：之前调试过一个 SPI 摄像头采集模块，每次一帧数据进来就是 960 字节，如果全部在顶半部里干，整个 CPU 的软中断占用直接飙到 60% 以上。后来把数据搬运和格式转换挪到底半部，顶半部只做 FIFO 数据读取，整体的帧率稳定了，CPU 占用也降到 15% 左右。这就是拆分带来的最直接收益。

2. 顶半部：把硬中断函数做"瘦"

2.1 注册中断的核心组织：request_irq 与 request_threaded_irq

注册中断处理函数，最常用的接口是 request_irq。它的原型如下：

c复制int request_irq(unsigned int irq, irq_handler_t handler,
                unsigned long flags, const char *name, void *dev);

其中 handler 就是顶半部函数，返回值为 irqreturn_t，可以返回 IRQ_NONE（不是我的中断）、IRQ_HANDLED（已处理）、IRQ_WAKE_THREAD（唤醒中断线程）。dev 参数很关键，在共享中断号的情况下，靠它在同一个 irq 上区分到底是哪个设备触发了中断。这个字段不能随便填 NULL，否则共享中断时你无法判断是不是你的设备，容易引发误处理。

request_threaded_irq 更灵活，它多了一个 thread_fn 参数。这个参数就是中断线程函数的入口，相当于把底半部显式注册成一个内核线程。如果你传了 thread_fn，但 handler 传了 NULL，内核会用默认的 irq_default_primary_handler 来唤醒线程，这也是后文要讲到的 threaded irq 的基础用法。

注册阶段还有两个容易踩的坑。一是 flags 参数，常见的有 IRQF_TRIGGER_RISING（上升沿触发）、IRQF_TRIGGER_FALLING（下降沿）、IRQF_TRIGGER_HIGH（高电平）、IRQF_TRIGGER_LOW（低电平）、IRQF_SHARED（允许多设备共享中断号）。电平触发和边沿触发的差异直接影响顶半部是否需要做"清中断"操作。电平触发的设备，如果你没有在 ISR 里清中断，中断会一直拉低，导致 CPU 死循环进入 ISR。边沿触发的设备则有可能丢中断，因为两次触发的间隔太短，硬件没有在边沿检测窗口内捕捉到。

2.2 顶半部里应该做什么、不能做什么

顶半部的黄金法则是：只做最紧迫、必须关中断才能做好的事，其它一切往下推。最紧迫的事通常包括以下几类：

• 从硬件 FIFO 里读取数据，防止数据覆盖丢失。比如串口寄存器只有 16 字节 FIFO，你不及时读走，硬件收到更多数据时会直接丢弃旧数据。
• 清除中断状态寄存器（ISR），把 pending 状态清掉，否则中断永远不会再次触发。
• 给硬件寄存器写入 ACK 确认，让硬件知道驱动已响应。
• 根据中断发生的事实，快速设置状态标记，或者唤醒等待队列里的消费者线程。

以网络驱动 realtek r8169 为例，它的中断处理函数中，顶半部就做这么几件事：读取 Interrupt Status 寄存器、判断是否是本设备中断、写回状态字清中断、把 napi_schedule 调起来调度网络收包。整个函数只有几十行，耗时通常不到 1 微秒。

顶半部里不能做的事就更多了，我挑最常见的讲：

• 不能调用任何可能睡眠的函数，包括 kmalloc(GFP_KERNEL)、mutex_lock、copy_from_user 等。需要分配内存就用 GFP_ATOMIC。
• 不能直接调用 wait_event、up 这类会唤醒后触发调度的操作。借助 workqueue 或底半部机制延后处理。
• 尽量避免大循环、耗时计算。比如在 ISR 里做浮点运算，在有些架构上还要保存浮点寄存器，开销极大。
• 尽量避免拿自旋锁的时间过长。自旋锁在中断里是可以用的，但不能长时间持有，否则会拖慢所有想拿同一把锁的进程。

我在实际调试中还踩过一个隐藏坑：顶半部里调用了 printk 输出调试日志。看似无害，但 printk 在某些配置下会触发控制台锁，而控制台锁又被别的进程持有，结果就在中断里自旋等待，白白浪费几十微秒。在低延迟场景下，这种"隐形开销"非常致命。调试时建议用 trace_printk，线上环境直接全部去掉。

3. 底半部机制选型面面观

3.1 softirq：内核自己用的"快车道"

底半部机制的第一个实现是 softirq（软中断）。它不是随意注册的，软中断类型在编译期就静态定义了，内核通过一个 open_softirq 的枚举来管理。目前内核中的软中断类型主要有：HI_SOFTIRQ、TIMER_SOFTIRQ、NET_TX_SOFTIRQ、NET_RX_SOFTIRQ、BLOCK_SOFTIRQ、IRQ_POLL_SOFTIRQ、TASKLET_SOFTIRQ、SCHED_SOFTIRQ、HRTIMER_SOFTIRQ、RCU_SOFTIRQ。驱动开发者一般不直接新增 softirq 类型，而是使用基于 softirq 封装出来的 tasklet 或其他机制。

softirq 的执行时机，主要在两个地方：一是顶半部处理完中断返回时，二是 ksoftirqd 内核线程中。local_bh_enable 时也会检查是否有 pending 的 softirq。它运行在中断上下文中，所以不能睡眠。但注意，同一种 softirq 在多核上可以同一时刻并行执行在多个 CPU 上。这意味着你写的 softirq 回调函数要做好并发保护，不能依赖简单的 per-CPU 变量解决问题。

为什么网络子系统特别依赖 softirq？因为网络收包路径需要极高的吞吐量，延迟要求介于硬中断和进程上下文之间。网络数据处理不能睡（比如操作 skb 的引用计数），也不适合每次都唤醒一个内核线程（线程调度的额外开销在高速率下会放大几百倍）。所以 softirq 以其"快速、并行、低调度开销"占据了网络收包最核心的位置。

使用 softirq 的门槛不低。一般驱动开发者直接操作 open_softirq 的场景极少，因为你要负责并发处理、CPU 亲和性、执行时机控制等一连串复杂问题。除非你需要极高性能的数据通路，否则不推荐直接在驱动里写自定义 softirq。

3.2 tasklet：串行化让新手少踩坑

tasklet 是基于 softirq 实现的，它本质上是 TASKLET_SOFTIRQ 类型软中断的一个使用场景。tasklet 做了串行化：同一个 tasklet 在同一时刻只会在一个 CPU 上执行，不会发生多核并发跑同一个 tasklet 的情况，这大大降低了驱动开发者的心智负担。你不需要考虑自己的 tasklet 会不会和另一个 CPU 上的自己打架，只需要考虑它和顶半部、其它 tasklet 之间的同步。

使用方式很简单：

c复制struct tasklet_struct my_tasklet;

void my_tasklet_handler(unsigned long data)
{
    // 处理耗时但不允许睡眠的工作
}

tasklet_init(&my_tasklet, my_tasklet_handler, 0);
tasklet_schedule(&my_tasklet);   // 从顶半部调度

tasklet_schedule 可以在中断上下文里安全调用。调度之后，tasklet 在稍后的某个时机会在软中断上下文中执行。tasklet 的“串行执行”特性让它在驱动开发中相当受欢迎，尤其适合 GPIO 按键、串口数据解析、传感器数据上报这类中等量级工作。

它的不足之处在于：

• 不能睡眠。tasklet 本质还是软中断上下文，调用可能导致睡眠的函数依旧会翻车。
• 同一个 tasklet 虽然不并发，但不同 tasklet 之间是可以并发的，而且如果多核同时调度多个 tasklet，它们会在各自的 CPU 上并行跑，所以要考虑多个 tasklet 之间共享数据的锁保护。
• tasklet 在高负载场景下可能被延迟执行，因为没有独立的优先级调度机制。

内核大佬们对 tasklet 的态度在慢慢变化。很多新代码正在从 tasklet 迁移到 threaded irq 或 workqueue，因为 tasklet 的线程安全边界太微妙。不过对于大多数传统驱动场景，它依然是一个好用的选择。

3.3 workqueue：需要睡眠时的大杀器

如果底半部要做的事情里，有必须睡眠的逻辑，比如等待 I2C 总线应答、操作 SDIO 卡、向用户空间发通知，那么 workqueue 就是正解。workqueue 将工作放到内核线程 kworker 中执行，这个时候上下文就是进程上下文，你可以用 mutex、msleep、wait_event_completion 等一切常规手段。

使用流程也很直观：

c复制struct work_struct my_work;

void my_work_handler(struct work_struct *work)
{
    // 可以睡眠的慢操作
}

INIT_WORK(&my_work, my_work_handler);
schedule_work(&my_work);   // 从顶半部调度

从顶半部通过 schedule_work 把工作排入系统默认工作队列，kworker 线程会在稍后执行。这里有一个需要特别注意的地方：系统默认的 events 工作队列是共享的，所以如果你在 work 处理函数里做了太长时间的操作（比如几百毫秒），会拖累所有使用默认工作队列的其他驱动。长期占用、频繁调用的场景，建议创建独立的 workqueue：

c复制struct workqueue_struct *my_wq;
my_wq = create_workqueue("my_driver_wq");
queue_work(my_wq, &my_work);

独立工作队列的优势是隔离性。即使你的工作写得比较慢，也不会明显拖慢其他驱动，问题排查时通过进程名也能一眼看到是哪个 workqueue 在忙。代价是多消耗一些内核线程资源，以及管理的复杂度略微上升。

workqueue 的唯一缺点是调度延迟比 softirq/tasklet 高。因为它要经过线程唤醒、调度器选择、运行等完整路径。一般的驱动场景几百微秒的延迟完全无所谓，但如果你的业务要求底半部 10 微秒内被执行，那就别用 workqueue，老老实实回去用 softirq 或 tasklet。

3.4 threaded irq：把整个中断线程化

request_threaded_irq 是中断处理的一种"暴力但优雅"的方案，做法是让内核为你的中断创建一个专用内核线程，顶半部只负责快速唤醒线程，然后所有处理逻辑都在线程里完成。对驱动作者而言，等于把"顶半部 + 底半部"整个封装成了一个整体，线程内部可以睡眠。

注册代码非常简单：

c复制static irqreturn_t my_irq_thread(int irq, void *data)
{
    // 这里跑在进程上下文，可以睡
    msleep(20);
    return IRQ_HANDLED;
}

request_threaded_irq(irq, NULL, my_irq_thread,
                     IRQF_TRIGGER_FALLING, "my_dev", dev);

注意 handler 传了 NULL，内核会调用默认的硬中断处理函数来唤醒线程。如果你想在唤醒线程前做点精简单的事，也可以显式传一个 handler，在 handler 里判断条件、读取必需的状态寄存器，然后返回 IRQ_WAKE_THREAD 让线程运行。

线程化中断带来了两个显著变化。

一是中断处理不再消耗硬中断上下文的时间。你可以在线程里坦然地拿 mutex、等待硬件完成、甚至做较重的协议解析。系统的硬中断延迟因此大幅降低，这对多设备、共享中断号、实时性要求较高的嵌入式系统帮助巨大。

二是中断线程可以被优先级调度和设置 CPU 亲和性。通过 sched_setscheduler 把中断线程调成 FIFO 实时优先级，可以保证某个关键设备的中断处理比其他普通线程抢占 CPU，这在工业控制领域是常见操作。

threaded irq 也有一个需要注意的短板：唤醒线程的过程引入了调度延迟。中断频繁触发时，线程可能跟不上硬件事件产生速度，导致事件积压。实际测试中，对于每秒几百次的 GPIO 中断或者低速串口，完全够用；对万兆网卡那种每秒百万级中断的场景就不合适了，必须用 NAPI + softirq。

4. 实际项目中的选型决策与优化实践

4.1 不同场景下的机制选择逻辑

到底选哪种底半部机制，不是"越高级越好"，而是要看硬件特性、数据量、延迟要求和开发维护成本。下面整理了我自己总结的选型逻辑，供参考。

这里多说一句 NAPI。网络子系统的"中断 + 轮询"混合模式，本质上是顶半部只做标志位和调度工作，然后通过 softirq 里的 poll 函数来批量收包。它充分利用了"中断唤醒、轮询收包"的策略，从而避免了高网络流量下频繁中断导致 CPU 宕机。如果你做网卡驱动，N**AOI 基本是标配，直接使用内核提供的 netif_napi_add 接口即可。

4.2 一次按键驱动的优化实测记录

我之前在一款 ARM 嵌入式板子上写一个矩阵键盘驱动。最开始的做法非常直接：在顶半部里读取 GPIO 状态、做按键滤波、上报 input 子系统，整个 handler 大概用了 15 微秒左右。一开始没问题，但系统同时跑着实时音频任务时，发现音频偶尔出现卡顿。

分析过程比较曲折。先用 trace 工具抓到硬中断的耗时分布，发现矩阵键盘的顶半部有时会跑到 30~40 微秒，原因是按键滤波里做了多次 GPIO 读取和软件延时。这 30 多微秒如果恰好撞上音频数据中断，就会导致音频 FIFO 溢出或欠载。

解决方案很直接：把 GPIO 状态读取和清中断留在顶半部（约 2 微秒完成），按键滤波和上报工作放到一个专用工作队列里。实际改动很小，但音频卡顿的问题消失了。这里需要明确一点：不是顶半部不能用，而是要避免在顶半部做不必要的延迟操作。

再看另一个例子。一块温湿度传感器通过 I2C 接口接入，I2C 读取一次需要十几毫秒的等待。如果我用 tasklet 来做这件事，直接会触发"在原子上下文里进入睡眠"的 bug。后来改成 request_threaded_irq，把所有 I2C 读取逻辑放进线程处理函数里，同时在线程里做错误重试，整个驱动干净很多。这也是 threaded irq 最大的价值：让驱动逻辑的写法回归"顺其自然"。

4.3 中断延迟测量：怎么判断优化到不到位

优化做得好不好，不能靠感觉，需要量化数据。比较常用的测量手段有几个。

第一种，查看 /proc/interrupts。它能显示每个中断号在每个 CPU 上的触发次数和设备名。如果某个中断号在某一个 CPU 上次数异常高，说明中断的 CPU 亲和性可能不均衡。通过 /proc/irq/IRQ_NUM/smp_affinity 可以手动调整中断分发策略。

第二种，使用 trace 系列工具。在 ftrace 的 irqsoff tracer 下能看到内核关闭中断的最长时间；preemptirqsoff 则同时追踪关抢占和关中断的最长时间。手动开启方式：

bash复制echo 0 > /sys/kernel/debug/tracing/tracing_on
echo irqsoff > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on
cat /sys/kernel/debug/tracing/trace

输出里会列出最长的关中断时间点和调用栈，这个数据直接反映了顶半部处理效率的上限。

第三种，自己写一个 GPIO 测试程序，通过一个 GPIO 引脚周期性地触发中断，在中断里记录另一个 GPIO 引脚翻转的时间戳，用示波器对比两个引脚的延迟。这个方法最直观，适合验证"中断到响应"的真实硬件延迟。

从经验值来看，一个经过合理优化的中断顶半部，在通用嵌入式 CPU 上的执行时间应该控制在 1~5 微秒以内。如果频繁看到顶半部超过 10 微秒，就要怀疑是不是把不该做的事放进来了。

5. 常见问题与排查技巧实录

5.1 折腾这么久最容易翻车的四个坑

在实际开发中，下面的问题我几乎每隔一段时间就会遇到一次，列成速查表供大家参考。

还有一个非常隐蔽的坑：ISR 里读某个状态寄存器，但该寄存器被硬件自动清除了，或者读取本身就有副作用。这类问题往往会在你添加调试读取之后"概率性修复"，实际上是你改变了读取时序，掩盖了本来存在的竞态条件。遇到这种玄学问题，优先梳理硬件寄存器手册，明确每一位的读写属性和清除方式。

5.2 排查中断相关性能问题的实操路径

如果你遇到的是"中断响应慢、系统卡顿"这类泛化问题，我建议按下面的路径排查：

先用 /proc/interrupts 确认中断分布和触发频率，看是否存在某个 CPU 上中断次数特别多的情况。如果频率高到每秒几万次，即使顶半部只有几微秒，CPU 的负担也相当可观。考虑用 irqbalance 服务打散中断到多核，或者手动设置 smp_affinity。

再用 ftrace 的 irqsoff 抓到最长的关中断区间。这时候经常发现"罪魁祸首"不是自己的驱动，而是其他模块的某次长时间关中断操作。比如某些老式网卡驱动在 ISR 里做了一大段寄存器读写，极耗时间。这种问题就只能换驱动、换方案，或者把业务中断的中断优先级调高。

最后如果问题依旧，用 perf 工具采样软中断执行的分布。比如：

bash复制perf record -e irq:softirq -a sleep 10
perf report

重点关注 NET_RX_SOFTIRQ 和 TASKLET_SOFTIRQ 占用的比例。如果软中断占了 CPU 超过 30%，说明底半部处理逻辑存在优化空间，例如加大网卡聚合、减少 wakeup 次数等。

5.3 用好内核提供的 debug 选项

内核配置里有几个和中断排查密切相关的开关，建议开发阶段打开：

• CONFIG_DEBUG_ATOMIC_SLEEP：检测原子上下文里是否发生了睡眠操作。这个一定打开，能帮你抓出一堆隐蔽 bug。
• CONFIG_PROVE_LOCKING：lockdep，检测锁的顺序错误、死锁风险。ISR 里拿锁和进程上下文拿锁的顺序问题，它能直接报出来。
• CONFIG_DEBUG_STACK_USAGE：检测内核栈使用量，防止栈溢出问题。
• CONFIG_IRQ_TIME_ACCOUNTING：让内核跟踪中断消耗的 CPU 时间，便于用 top、pidstat 等工具看到 irq 和 softirq 的 CPU 占用。

这几个开关虽然会带来一些额外开销，但在调试阶段非常值得。线上环境再酌情关闭。

写在最后

顶半部和底半部的机制，表面上看只是"中断处理函数拆成两段"这么简单，但真正理解它需要吃透中断上下文、调度器、并发控制这三条主线。我在实际项目中见过太多人把 tasklet 当万能药，结果睡眠违规；也见过有人把所有逻辑塞进顶半部导致实时任务抖动。中断处理优化的核心心法是：能用最少时间解决的问题绝不拖到慢路径，反之能放到慢路径处理的事绝不阻塞快路径。

最后再分享一个调试习惯：每写一段中断相关代码，都要问自己三个问题——我这个函数会不会睡眠？最多执行多少时间？多个 CPU 上会不会同时跑？这三个问题想清楚了，中断这部分代码基本就能站得住。