Linux中断处理机制详解：顶半部与底半部的设计哲学与实践

先聊个我踩过的坑。早几年调一块 ARM 平台的中断处理，板子一跑高负载网络吞吐测试就丢包，抓包看中断次数没少，但应用层就是响应不过来。查了半天才发现问题不是出在中断没触发，而是中断处理函数里干了太多琐碎活：又是读寄存器、又是清状态、还顺手做了个内存拷贝，把整个中断路径拖得死死的。那次之后我才真正意识到，Linux 内核把中断拆成“顶半部”和“底半部”这两个阶段，不是架构师闲得没事搞出来的花架子，而是实实在在救了所有做驱动、做嵌入式的开发者一命。

这篇文章我打算从设计思路讲起，把两半机制为什么存在、各自该干什么、实际代码怎么写、出了状况怎么排查，完整走一遍。如果你正在写字符设备驱动、网卡驱动，或者做嵌入式 BSP 适配，对“中断处理耗时过高”“中断里能不能睡眠”“该选 tasklet 还是 workqueue”这类问题一头雾水，那这篇就是冲着你来的。

1. 为什么中断处理非要拆成两半

1.1 中断处理的第一原则：快

中断是什么？是硬件告诉 CPU“我这里有事了，你赶紧来处理”。CPU 收到中断信号后，会立刻停下手头正在跑的进程，跳转到对应的中断处理函数。这件事发生的时候，CPU 已经进入一种“特殊状态”——中断上下文（atomic context）。在这个状态下，处理器会屏蔽部分或全部中断，也就是说，如果你的中断处理函数执行了 10 毫秒，那么这 10 毫秒里，其他中断统统进不来，卡在后面排队。

这就很致命了。想象一个网卡，每收到一个包就触发一次中断。如果每次中断处理要花掉 5 微秒，那当网络流量上来的时候，中断处理的耗时很快就超过了两次中断之间的间隔。结果是中断还没处理完，新的中断又来了，然后就是丢包、缓冲区溢出、系统响应卡顿。

所以中断处理必须满足一个铁律：快，越短越好。但现实中，硬件事件来了之后，需要考虑的事往往很多。以网卡收包为例，你要告诉硬件“这个包我收了，你把下次中断准备好”，要检查收到的包有没有错误，要把数据从硬件的 DMA 缓冲区拷到内核内存，还要把包交给协议栈去处理。最后这一步尤其耗时，协议栈处理一个 TCP 包，涉及路由查找、TCP 状态机、socket 队列、唤醒用户进程，一套下来远远超过中断上下文能承受的时间范围。

这就出现了一个矛盾：中断处理既要求极短时间，又必须完成大量复杂工作。顶半部/底半部的拆分，就是为了解决这个矛盾而生的。

1.2 两半设计背后的本质思路

Linux 的解法是“先记账，后算账”。把中断处理拆成两个阶段：

• 顶半部（top half）：也就是硬中断处理函数。它只做最紧急、必须立刻完成的事情，比如告诉硬件“我收到中断了”、读一下硬件状态寄存器的关键信息、用irq_work或软中断机制把自己的“后续任务”挂到队列里，然后立刻返回。整个流程要求在微秒级别跑完。
• 底半部（bottom half）：延后执行的真正工作。它运行在稍后的某个安全时机，此时 CPU 已经解除了对中断的屏蔽，甚至可以运行在进程上下文（比如工作队列），可以做更耗时的事情，比如网络协议栈处理、数据拷贝、复杂计算。

这个思路你可以理解成餐厅里的场景：客人进来，服务员先记下菜单（顶半部，快），然后把菜单递给后厨，后厨慢慢炒菜（底半部，慢但可以等）。如果让客人进来之后，服务员直接进后厨把菜全部炒完再接待下一个客人，那餐厅早就黄了。

把两半拆开之后，硬中断的占用时间被压缩到极致，系统整体的实时性、吞吐量都得到了保证。这也是为什么 Linux 能同时承受大量外部设备和极高数据吞吐量的根本原因之一。

1.3 五种执行上下文的全局观

想要真正搞清楚中断处理，脑子里得先有一张“CPU 执行上下文”的全局图。Linux 内核里，代码跑在不同的上下文中，哪些事情能做、哪些不能做，完全由上下文决定。

搞清楚这张表，你在写驱动的时候就能避免大量低级错误。最典型的就是“在硬中断里调用kmalloc时用了GFP_KERNEL标志导致睡眠”——一旦睡眠发生在中断上下文，内核直接报BUG: scheduling while atomic，严重的直接死锁、系统崩溃。区别一个操作能不能做，根本判断标准就是：你所在的上文是否允许睡眠。

顶半部里不能睡眠，底半部里要分情况——软中断/tasklet 里仍然不能睡眠，工作队列里可以。这个差异直接决定了你的“延后工作”该选哪种底半部机制。后面我会专门展开说明。

2. 顶半部的实现细节：中断来了到底该干什么

2.1 注册一个顶半部处理函数

顶半部在代码里的载体，是中断处理函数。以 Linux 设备驱动里最常见的注册接口为例：

c复制static irqreturn_t sample_irq_handler(int irq, void *dev_id)
{
    /* 顶半部处理代码 */
    return IRQ_HANDLED;
}

/* 在驱动probe函数中注册中断 */
ret = request_irq(irq_num, sample_irq_handler,
                  IRQF_TRIGGER_RISING, "sample_device", dev);
if (ret) {
    pr_err("failed to request irq %d, ret=%d\n", irq_num, ret);
    return ret;
}

request_irq是传统的注册方式。传入的参数里，irq_num是中断号，dev_id是传给处理函数的私有数据指针，这个指针同时还有一个重要作用：free_irq时用来匹配释放对应的中断，避免误删别人的处理函数。共享中断（多个设备共用一条 IRQ 线）的时候，dev_id是区分设备的关键，不能省略。

处理函数的返回值是irqreturn_t类型，一般用IRQ_HANDLED表示“这个中断是我处理的”，用IRQ_NONE表示“虽然触发了但我这儿没发过中断”。内核会统计返回值，辅助调试共享中断的问题。

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

基于“快”的原则，顶半部的最佳实践非常明确。应该做的事情包括：

• 给硬件寄存器写入“中断已确认”的字样，清掉中断挂起位。这一步如果漏了，硬件会认为中断没被处理，一直触发，导致 CPU 卡死在中断里。
• 拷贝硬件状态寄存器中的关键信息到内存变量。
• 从硬件 FIFO 或 DMA 缓冲区中抢救少量宝贵数据（如果硬件缓冲区很小，再不取就被新数据覆盖的话）。
• 通过tasklet_schedule、schedule_work、softirq等接口，把真正的处理工作丢给底半部。
• 处理周期极短、完全可以在几微秒内完成的任务，也可以就地干完。

绝对不能做的事情包括：

• 调用会导致睡眠的函数，比如kmalloc(..., GFP_KERNEL)、mutex_lock、msleep、copy_to_user。
• 访问用户空间内存地址。
• 执行耗时较长的循环、复杂的计算或大块内存拷贝。
• 直接调用printk（调试时偶尔用一下可以理解，但生产环境里必须去掉。printk在中断上下文同样可能导致睡眠，而且会严重拖慢中断执行）。

我做驱动开发时有个习惯：顶半部只留三类语句——寄存器读写、状态变量赋值、底半部调度函数调用。如果处理函数超过 30 行，基本就要警惕是不是塞了太多不该塞的东西。这个习惯帮我避开了大量莫名其妙的性能问题。

2.3 request_irq 与 request_threaded_irq 的取舍

老驱动里基本全是request_irq，但新内核里其实更推荐用request_threaded_irq。两者的区别是，后者把顶半部注册成一个中断线程，允许在处理函数里睡眠。

c复制static irqreturn_t sample_threaded_irq_handler(int irq, void *dev_id)
{
    /* 这里已经是线程上下文，可以睡眠 */
    return IRQ_HANDLED;
}

ret = request_threaded_irq(irq_num, NULL,
                           sample_threaded_irq_handler,
                           IRQF_TRIGGER_RISING,
                           "sample_device", dev);

request_threaded_irq的第二个参数是顶半部处理函数，传NULL表示内核使用默认的顶半部实现——这个实现里只做一件事：把中断请求推给内核线程去执行。第三个参数才是真正执行的中断线程函数。

这种设计（threaded IRQ）特别适合那些硬件本身就慢、处理过程复杂的设备，比如 I2C 触控屏、MMC 卡。这类设备的中断处理经常需要和控制器打交道，而控制器又有自身的时序要求，动不动就要等、要重试，放在传统硬中断里根本没法写。线程化之后，你可以痛痛快快地在中断处理里调用wait_for_completion、msleep，不用担心睡眠问题。

但是线程化不是免费的，它的代价是实时性下降。硬中断只要触发就立即执行，而中断线程需要被内核调度器挑中才能跑，这中间存在调度延迟。所以对时序要求极其苛刻的场景（比如高精度 PWM、高速数据采集），还是得用传统硬中断加底半部的方式。

2.4 顶半部现场实录：一个简化版的网卡收包中断

拿网卡收包打个样，你就知道顶半部到底有多“省”。真实网卡驱动（比如 Intel 的 igb 驱动）里，收包中断顶半部大致做这些事情：

c复制static irqreturn_t igb_msix_ring(int irq, void *data)
{
    struct igb_q_vector *q_vector = data;

    /* 关闭该队列的中断，防止处理期间再次触发 */
    if (q_vector->rx.ring)
        writel(0, q_vector->rx.ring->ims_reg);

    /* 把真正的收包处理任务挂到 NAPI 上 */
    if (napi_schedule_prep(&q_vector->napi)) {
        __napi_schedule(&q_vector->napi);
    }

    return IRQ_HANDLED;
}

全程除了写寄存器、调napi_schedule_prep，就没别的了。真正收包、整理 skb、交给协议栈的工作，全部在 NAPI 的 poll 机制里延后处理了。这就是顶半部设计的标准典范——把“告诉硬件我来了”和“真正干活”彻底分开。

3. 底半部的三种机制：软中断、tasklet 与工作队列

底半部不是一种单一机制，而是三套方案的统称。选哪个，取决于你的延后工作需要满足什么条件。

3.1 软中断：性能之王，但门槛极高

软中断是内核里最“快”的底半部机制。它运行在软中断上下文，仍然是原子性的，不能睡眠，但允许被硬中断打断。网络收发包、块设备读写、时钟事件处理，这些对吞吐量要求极高、对延迟极度敏感的核心路径，用的都是软中断。

但是软中断只对内核核心子系统开放。如果你想在驱动里自己注册一个软中断，必须静态分配enum索引，改内核源码里的kernel/softirq.c，侵入性非常大。对于普通驱动开发者来说，我不建议碰它，除非你在维护内核网络或块设备子系统。

软中断跟硬中断最大的区别是执行时机。硬中断是 CPU 被迫立刻跳过去处理，而软中断是在内核代码的某些固定点（比如中断处理函数返回前、local_bh_enable时）被主动检查并执行的。在 Linux 里，为了保证网络收包性能，软中断也会被ksoftirqd内核线程拉起执行。

关于软中断，驱动开发者真正需要关心的，反而是ksoftirqd这个内核线程。曾经有过一个经典问题：当软中断负载过高时，ksoftirqd会占满整个 CPU，让用户进程拿不到时间片。后来内核加入了时间片限制和NEED_RESCHED机制，避免软中断饿死用户态进程。但从驱动的角度，你的底半部工作如果特别耗时，就别塞进软中断/tasklet里，丢给工作队列更合适。

3.2 tasklet：驱动界的老朋友

tasklet 是基于软中断实现的一种接口，专门给驱动开发者用。它有两个关键特性：

• 同一个 tasklet 在多核系统中保证串行执行，不会出现两个 CPU 同时跑同一个 tasklet 的情况。
• tasklet 运行在软中断上下文，不能睡眠。

第二个特性常常被忽略，然后引发惨案。我在代码审查里看到无数次tasklet里调用usb_control_msg或者wait_event的写法，这些都是会睡眠的操作，放在 tasklet 里迟早出问题。

tasklet 的用法很简单：

c复制/* 定义并初始化 tasklet */
void my_tasklet_func(unsigned long data);
DECLARE_TASKLET(my_tasklet, my_tasklet_func, 0);

/* 顶半部里调度 */
tasklet_schedule(&my_tasklet);

/* 不再使用时销毁 */
tasklet_kill(&my_tasklet);

调度之后，tasklet 会在内核回到软中断处理流程时被执行。因为其简单易用的接口，几十年来它都是驱动里最常见的底半部方案。但有一个问题：tasklet 在多核上的负载均衡能力差，因为同一个 tasklet 只能同时跑在一个 CPU 上。而且新内核逐步在将 tasklet 往tasklet_hi、tasklet_hi_schedule这种更高优先级的变体迁移，同时也推荐新驱动优先使用工作队列或 threaded IRQ。

3.3 工作队列：能睡眠的底半部

工作队列是三种机制里唯一运行在进程上下文的底半部，由内核的kworker线程执行。这意味着你可以在工作队列的任务里使用各种会睡眠的同步原语：mutex_lock、wait_event、msleep，随便用。

c复制static void my_work_func(struct work_struct *work);
DECLARE_WORK(my_work, my_work_func);

/* 顶半部里调度 */
schedule_work(&my_work);

/* 如果你要保证同一个work不并发执行，可以用 */
schedule_work_on(cpu, &my_work);  /* 指定CPU */

工作队列的使用门槛最低，但延迟相对也最高。从schedule_work到kworker真正执行，中间隔着一个内核线程调度延迟，通常几十微秒到几百微秒不等。对时间要求不高的底半部任务，比如传感器数据上报、LED 状态刷新、周期性日志落盘，用工作队列再合适不过。

工作队列有一种常见变体：自定义工作队列。当你的设备需要独立的执行线程、避免和其他驱动共享 kworker 资源时，可以用alloc_workqueue创建专属队列：

c复制struct workqueue_struct *my_wq = alloc_workqueue("my_wq",
                                                  WQ_HIGHPRI | WQ_UNBOUND,
                                                  0);
queue_work(my_wq, &my_work);

WQ_HIGHPRI会让这个队列的线程优先被调度，WQ_UNBOUND则允许任务在多个 CPU 间迁移。这里有个细节：如果底半部任务之间有严格的依赖关系，建议使用WQ_UNBOUND时配合alloc_ordered_workqueue，它可以保证队列里的任务严格按顺序执行，避免并发引发竞态。

3.4 三种机制选型速查

我整理了一个选型表，基本覆盖了驱动开发里 90% 的场景：

这个表是我多年改 vim 驱动、GPIO 按键驱动、网卡驱动时沉淀出来的。照这个方向选，不会出大错。

4. 实操手记：从零实现一个带底半部的中断处理驱动

理论说了一堆，接下来手写一个真实的例子。场景很简单：一个 GPIO 按键，按下时触发外部中断，顶半部负责记录时间戳并关中断，底半部用 tasklet 完成按键去抖和上报工作。我会把这个例子拆成几个关键步骤，每一步讲清楚“为什么”。

4.1 初始化与中断注册

先看整体框架。为了简洁，我略去 GPIO 申请和平台相关的代码，聚焦中断相关部分：

c复制#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/gpio.h>
#include <linux/delay.h>

#define KEY_GPIO  123 /* 示例GPIO编号 */
#define KEY_IRQ   456 /* 示例中断号 */

struct key_data {
    int irq;
    unsigned long last_jiffies;
};

static struct key_data key_info;

static void key_tasklet_func(unsigned long data);
static DECLARE_TASKLET(key_tasklet, key_tasklet_func, 0);

/* 顶半部 */
static irqreturn_t key_irq_handler(int irq, void *dev_id)
{
    struct key_data *kd = dev_id;

    /* 记录时间戳：这个数据在tasklet中会用到 */
    kd->last_jiffies = jiffies;

    /* 禁用中断，防止在tasklet处理完成前再次触发 */
    disable_irq_nosync(irq);

    /* 调度tasklet执行底半部工作 */
    tasklet_schedule(&key_tasklet);

    return IRQ_HANDLED;
}

/* 底半部 */
static void key_tasklet_func(unsigned long data)
{
    /* 模拟按键去抖：底半部里不能sleep，所以用忙等 */
    unsigned long start = jiffies;
    while (time_before(jiffies, start + msecs_to_jiffies(10))) {
        cpu_relax();
    }

    /* 上报按键事件：实际驱动里通常会放到工作队列里去上报
       这里仅为演示tasklet中的处理流程 */
    pr_info("key pressed at %lu\n", key_info.last_jiffies);

    /* 重新使能中断 */
    enable_irq(key_info.irq);
}

static int __init key_drv_init(void)
{
    /* 省略GPIO申请配置 */
    key_info.irq = KEY_IRQ;
    return request_irq(key_info.irq, key_irq_handler,
                       IRQF_TRIGGER_FALLING,
                       "key_drv", &key_info);
}

static void __exit key_drv_exit(void)
{
    tasklet_kill(&key_tasklet);
    free_irq(key_info.irq, &key_info);
}

module_init(key_drv_init);
module_exit(key_drv_exit);
MODULE_LICENSE("GPL");

这段代码的核心设计点是：顶半部拿到关键状态（时间戳）后立刻关中断，防止同一按键在去抖期间重复触发，然后丢给 tasklet。tasklet 跑完后再开中断。这样就把“去抖等待”从顶半部移走了，顶半部本身只花了极短的时间。

4.2 踩坑点：tasklet 里的忙等为什么不好

你可能会问：按键去抖用忙等，CPU 不是白烧了 10 毫秒吗？确实如此，但这个例子是为了展示 tasklet 的局限——不能睡眠。真实产品里，按键去抖更常见的做法是用高精度定时器（hrtimer）延后执行，或者在开启中断前先让硬件自带消抖电路过滤。

如果你确实需要在底半部里做较长时间的等待，正确做法是把后续逻辑挪到工作队列：

c复制static void key_work_func(struct work_struct *work);
static DECLARE_WORK(key_work, key_work_func);

static void key_tasklet_func(unsigned long data)
{
    /* 这里不再忙等，直接把真正需要耗时的工作丢给workqueue */
    schedule_work(&key_work);
}

static void key_work_func(struct work_struct *work)
{
    /* 工作队列里可以sleep，去抖可以睡得安心 */
    msleep(10);
    pr_info("key pressed at %lu\n", key_info.last_jiffies);
    enable_irq(key_info.irq);
}

这样任务被拆成了两级：tasklet 只做快速转交，真正的阻塞操作全部放到工作队列里。这其实正是内核社区越来越倾向于“用线程化中断 + 工作队列替代 tasklet”的原因——层级太多，反而增加理解成本和出错概率。

4.3 能睡觉的线程化版本

同样的按键驱动，换成request_threaded_irq之后，代码一下子清爽很多：

c复制static irqreturn_t key_threaded_handler(int irq, void *dev_id)
{
    struct key_data *kd = dev_id;

    kd->last_jiffies = jiffies;
    msleep(10); /* 去抖 */
    pr_info("key pressed at %lu\n", kd->last_jiffies);

    return IRQ_HANDLED;
}

ret = request_threaded_irq(key_info.irq, NULL,
                           key_threaded_handler,
                           IRQF_TRIGGER_FALLING,
                           "key_drv", &key_info);

NULL顶半部意味着内核帮你做了“快速确认+唤醒线程”的工作。中断线程里想睡多久睡多久。对按键这类低频率的外设，这种写法最省心。

4.4 中断释放与延迟释放的细节

free_irq前有个坑：如果你的底半部还在跑，直接free_irq可能会崩。通常的规范是：

• 在exit函数里先disable_irq，确保顶半部不会再被调度。
• 再tasklet_kill或cancel_work_sync，确保底半部已结束或不会再次启动。
• 最后free_irq。

顺序不能乱。我在一个项目里就因为先free_irq再tasklet_kill，导致 tasklet 在驱动卸载后仍然访问已释放的dev_id指针，触发内核崩溃。排查时 core dump 指向的地址已经毫无意义，折腾很久才定位到生命周期顺序问题。

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

5.1 中断处理耗时太长，怎么量化定位

遇到系统响应慢、负载飙升，第一件事不是猜，而是量。最直接的办法是看中断处理函数的耗时。

在内核里，开启动态中断检测：

bash复制echo 2 > /proc/sys/kernel/irq_log_time

这个节点会记录每个中断处理函数的执行时间。更细的工具是irqsoff tracer 和function_graph，前者追踪中断关闭的最长时间，后者能看到中断处理函数内部每个子函数的耗时分布。

bash复制# 打开 function_graph 追踪
cd /sys/kernel/tracing
echo function_graph > current_tracer
echo key_drv > set_ftrace_filter
echo 1 > tracing_on

看到耗时分布后，再对照处理函数代码，基本能锁定是哪个函数在里面磨蹭。我遇到过的一个典型案例：有驱动在顶半部里写了printk，看着就一行日志，但 console 输出到串口是同步阻塞的，一个字符一个字符地往外送，硬生生把中断处理从几微秒拉到几百微秒。去掉之后，性能问题立刻消失。

5.2 中断风暴：CPU 被同一个中断打满

如果一个硬件中断触发极其频繁，CPU 就会长期困在中断处理中，导致系统卡死，这种状态叫中断风暴（interrupt storm）。

排查思路很直接：

bash复制# 查看各个中断的触发次数
cat /proc/interrupts

# 确认是不是某个CPU的中断过于集中
watch -n 1 cat /proc/interrupts

/proc/interrupts每一列代表一个 CPU，如果你看到某个中断号在一个 CPU 上的计数瞬间暴涨，而且设备对应的计数异常增长，那就是中断风暴。

常见原因和处理办法：

顺便说一句，对于使用disable_irq/enable_irq做互斥的场景，一定要警惕这俩函数本身的行为。disable_irq会等正在执行的中断处理函数返回，如果你的顶半部正在等一个底半部才释放的自旋锁，而底半部又被等在中断后面，那就是死锁。内核参考文档里明确建议中断上下文里使用disable_irq_nosync而不是disable_irq，原因就在于此。

5.3 底半部被饿死：软中断耗尽 CPU

前面提到过ksoftirqd占满 CPU 的问题。这类问题在驱动层面常见于：一个设备频繁调度 tasklet，而 tasklet 里又有高耗时操作，导致软中断处理永远跑不完。ksoftirqd长时间飙到 100%，用户进程响应变慢。

查看是不是软中断负载过高：

bash复制top -1
# 观察 si 那一行，si 表示软中断消耗的CPU时间

如果si长期在 50% 以上，说明你底半部的任务量已经不正常了。解决办法通常是：

• 把耗时的 tasklet 任务迁到工作队列。
• 检查顶半部是否频繁触发，适当做中断合并（coalescing）。
• 对于网络类设备，确认 NAPI 的权重配置合理，不要每次 poll 处理无限多的包。

5.4 多核环境下的中断均衡：irqbalance 与中断亲和性

现代系统里，多核 CPU 意味着你可以把不同设备的中断分摊到不同核心上，避免所有中断挤在一个核上。

查看和设置中断亲和性：

bash复制# 查看中断18当前绑定的CPU
cat /proc/irq/18/smp_affinity

# 把中断18绑定到CPU0和CPU1
echo 3 > /proc/irq/18/smp_affinity

有些系统里跑着irqbalance服务，它会自动动态调整中断亲和性，但自动调整有时不一定符合你的性能预期，尤其是在实时性敏感的应用里。我一般会选择手动绑定关键设备中断，把irqbalance关掉，让 CPU0 专心中断处理，用户态任务绑到其他核。这样行为可预期，也好排查。

5.5 RT 补丁和中断线程化对两半机制的影响

如果你用的是 PREEMPT_RT 内核（实时内核补丁），中断处理模型会有较大变化。在 RT 内核里，几乎所有的硬中断都会被强制线程化，只有少数标记为IRQF_NO_THREAD的中断保持硬中断处理。这意味着你写的顶半部代码，在 RT 内核上实际运行在中断线程中，行为会和你预期的硬中断环境不同。

这个影响主要体现在：

• 顶半部的优先级由线程优先级控制，而不是硬件中断优先级。
• 原本在顶半部不能睡的代码，在 RT 内核里可以合法睡眠（因为实际是线程上下文）。

做嵌入式实时系统适配时，一定要查清楚目标内核是否开启了 RT 配置，否则你用“传统五步”假设写出来的中断代码，跑在 RT 内核上可能完全是另一种调度行为。

6. 一些我踩过的坑和最终建议

最后聊几点我在多个项目中反复遇到、每次都有人翻车的细节。

第一，中断共享的时候，顶半部一上来就清中断标志是错的。共享中断意味着多个设备共用同一条 IRQ 线，你在处理函数里清了中断标志，可能把别的设备的中断状态也清掉了，导致别的设备永久卡死。正确的做法是先读硬件寄存器确认本次中断是不是自己这个设备发出的，确认了再清，不是就返回IRQ_NONE。

第二，tasklet 和工作队列并不是越高级越好。有些刚上手的新人一看工作队列能睡眠，就什么都不管往里塞。但实际上工作队列的调度延迟非常高，如果业务对抖动敏感（比如音频流采集），你会发现数据明显不规律。我经历过一次音频设备驱动，底半部从 tasklet 改成工作队列之后，buffer 周期从稳定变成了毛刺一堆。最终又改回 tasklet + 环形缓冲区的方案才解决。选型真的要看场景，不要为了省事而无脑用某一招。

第三，中断处理函数里的每一行代码都要问“我在哪个上下文”。这不是小题大做。即便是一个简单的printk，在某些配置下都可能引发 deep 的连锁反应。我在调试时有一个习惯：在驱动源码开头加一段注释，写明这个驱动里哪些函数在中断上下文、哪些在进程上下文、哪些会被并发调用，一旦上下文变了就主动更新注释。这个习惯在多人协作时尤其有用，能省掉无数脑细胞。

第四，不要把顶半部写得过于“节约”。有一个反方向的坑：有人过度追求顶半部短小，连必要的状态保存都推迟到底半部去做，结果底半部被更高优先级任务抢占，丢失了关键状态。顶半部不是越短越好，而是“该干的短活都干完”才好。比如把寄存器里的关键数据保存在内存里，这种几纳秒的活，别省。

Linux 中断处理从顶半部到底半部的这套设计，可以说是整个内核性能与实时性平衡的精髓。把紧急但不耗时的事放在前面，把耗时但不紧急的事放在后面，本质上是一种对计算资源的理性分配。写驱动的时候多想一想自己处在哪个上下文、这个任务能不能等、等多久，思路一旦清晰，代码写出来就顺了。