Linux Bottom Half 机制解析:tasklet 与 workqueue

第一章：中断为什么需要 Bottom Half

1.1 硬中断不能执行太久

Linux 驱动里最容易犯的错误，就是把大量逻辑直接塞进中断函数。比如 UART 中断里直接做协议解析、内存申请、链表操作，甚至 printk 调试。设备速率一高，CPU 很快就会被 IRQ 打满，系统出现明显卡顿，严重时连调度器都抢不到时间片。

Linux 内核很早就把中断处理拆成了两部分：Top Half 和 Bottom Half。Top Half 只负责最关键的事情，例如读取状态寄存器、清中断、搬运 FIFO；剩余耗时逻辑延后处理。这样做的核心目的并不是“异步”，而是尽量缩短关中断时间，提高整个系统实时性。

1.2 Bottom Half 的本质

所谓 Bottom Half，本质就是“延迟执行”。硬中断只负责快速响应硬件，真正的数据处理放到稍后执行。Linux 早期出现过 BH、Task Queue，后来逐渐统一到了 softirq 体系，tasklet 和 workqueue 都是建立在它之上的封装，整个流程其实很简单：

IRQ到来  ↓Top Half快速处理  ↓唤醒Bottom Half  ↓延后执行耗时逻辑

网卡、USB、块设备、串口、SPI 驱动基本都在使用这套模型。尤其高速设备里，如果没有 Bottom Half，CPU 会长期陷入硬中断上下文，系统吞吐会急剧下降。

第二章：Softirq 与 Tasklet

2.1 Softirq 是真正的底层机制

Linux Bottom Half 的核心其实是 softirq。内核里预定义了多个 softirq 类型，例如网络收包、定时器、tasklet 都属于 softirq。硬中断退出时，内核会检查 pending bitmap，如果发现有 softirq 被触发，就立即执行对应处理函数。

softirq 最大特点是性能高，因为它仍然运行在中断上下文，不需要线程切换。但问题也很明显：不能睡眠、不能阻塞，而且同一种 softirq 可以在多个 CPU 上同时运行，所以开发难度很高。Linux 网络栈里的 NET_RX_SOFTIRQ 就是典型代表。

内核里能看到：

enum {    HI_SOFTIRQ,    TIMER_SOFTIRQ,    NET_TX_SOFTIRQ,    NET_RX_SOFTIRQ,    TASKLET_SOFTIRQ,};

很多人以为 tasklet 是独立机制，其实它本质上还是跑在 TASKLET_SOFTIRQ 上。

2.2 tasklet 为什么出现

softirq 性能虽然高，但驱动开发太痛苦。因为 SMP 下同一个 softirq 可能并发运行，锁处理稍微有问题就会出现竞态。所以 Linux 后来又封装了一层 tasklet，用来简化驱动开发。

tasklet 最大特点是“同一个 tasklet 实例不会并发执行”。这个特性非常重要，因为它天然避免了 SMP 重入问题。很多老驱动，尤其网卡和串口驱动，大量使用 tasklet，定义方式也很简单：

staticvoiduart_tasklet_func(unsignedlong data);DECLARE_TASKLET(uart_tasklet,                uart_tasklet_func,                0);

中断里直接调度：tasklet_schedule(&uart_tasklet);

这样硬中断里只做快速收数，协议解析放到 tasklet 里完成，中断延迟会明显降低。

第三章：tasklet 执行过程

3.1 tasklet 如何运行

tasklet 本质上只是 softirq 的一个链表节点。调用 tasklet_schedule() 后，内核会把对应 tasklet 挂到 TASKLET_SOFTIRQ 队列，然后在 softirq 阶段统一执行，实际流程：

IRQ ↓tasklet_schedule() ↓raise_softirq() ↓__do_softirq() ↓tasklet_action() ↓tasklet func

由于 tasklet 仍然运行在软中断上下文，所以限制其实很多。比如不能 sleep、不能 mutex_lock、不能调用可能阻塞的接口。如果在 tasklet 里执行 schedule()，内核会直接报 BUG。

很多驱动早期喜欢在 tasklet 里做大量事情，例如 SPI 数据解析、协议栈处理，但后来发现这种模式很容易导致 softirq 长时间占用 CPU，引发系统抖动。

3.2 一个典型 tasklet 驱动

下面这个 UART 驱动结构在老内核里很常见。中断只负责快速读 FIFO，真正解析放到 tasklet。

irqreturn_tuart_irq(int irq, void *dev_id){    struct uart_dev *uart = dev_id;    uart_read_fifo(uart);    tasklet_schedule(&uart->rx_tasklet);    return IRQ_HANDLED;}

tasklet 处理：

staticvoiduart_rx_tasklet(unsignedlong data){    struct uart_dev *uart =        (struct uart_dev *)data;    parse_frame(uart);}

这种结构的好处很明显：IRQ 时间很短，不会长时间占用 CPU。但问题也同样明显，如果 parse_frame() 太重，softirq 仍然可能跑飞，所以现代驱动已经越来越少直接使用 tasklet。

第四章：workqueue 机制

4.1 为什么需要 workqueue

tasklet 解决了“延后执行”的问题，但它依然运行在中断上下文，因此很多事情仍然做不了。比如 mutex、文件 IO、copy_to_user、msleep 这些操作都可能睡眠，而软中断上下文绝对不允许睡眠。

于是 Linux 又引入了 workqueue。它的核心思想很直接：既然中断上下文限制太多，那干脆把 Bottom Half 放进内核线程里执行。这样驱动就可以像普通进程一样运行复杂逻辑，workqueue 最大区别就是：

tasklet：中断上下文workqueue：进程上下文

这意味着 workqueue 可以安全睡眠。

4.2 workqueue 的运行方式

workqueue 本质上就是“工作队列 + kworker 内核线程”。驱动提交 work 后，真正执行逻辑的是内核 worker thread。

定义方式：struct work_struct rx_work;

初始化：

INIT_WORK(&uart->rx_work,          uart_rx_work_func);

调度：schedule_work(&uart->rx_work);

worker 执行：

staticvoiduart_rx_work_func(            struct work_struct *work){    mutex_lock(&uart->lock);    process_data();    mutex_unlock(&uart->lock);}

这里已经能安全使用 mutex，因为它本质上已经属于线程上下文。

第五章：高级 workqueue

5.1 delayed_work

Linux 里很多周期任务并不需要 timer + 线程两套机制，直接 delayed_work 就够了。它本质上是“延迟执行的 workqueue”。

初始化：INIT_DELAYED_WORK(&monitor_work,                  monitor_func);

延迟调度：schedule_delayed_work(&monitor_work,                      msecs_to_jiffies(1000));

1 秒后自动执行。很多驱动里的 watchdog、状态轮询、链路检测其实都是这么做的，因为它比 timer 更容易写复杂逻辑。

5.2 单线程 workqueue

默认 workqueue 可能并发执行。如果驱动本身是串行状态机，例如 SPI、I2C、固件升级，就可能需要单线程 workqueue。

创建方式：wq = create_singlethread_workqueue(            "uart_wq");

提交：queue_work(wq, &uart->rx_work);

这样所有任务都会进入同一个 worker thread，不会出现并发执行问题。很多老驱动喜欢靠 spinlock 硬控并发，但实际上单线程 workqueue 更稳定，也更容易调试。

第六章：现代 Linux 为什么减少 tasklet

6.1 tasklet 的问题

tasklet 当年很流行，因为它比 workqueue 更轻量，延迟也更低。但随着 Linux 内核越来越强调 PREEMPT_RT、实时性以及线程化，tasklet 的问题逐渐暴露出来。

首先它仍然属于 softirq，上下文限制太多；其次 softirq 本身不太适合实时系统；再加上 SMP 下调试困难，很多 tasklet 问题都属于偶发 BUG，定位成本极高，尤其高负载下，经常出现：

softirq占满CPUksoftirqd飙高系统延迟抖动

这些问题在网络场景非常典型。

6.2 threaded irq 正在替代 tasklet

现代 Linux 更推荐 threaded irq + workqueue 组合。request_threaded_irq() 可以直接把 IRQ 后半部分放进线程里执行，很多场景已经不再需要 tasklet，比如：

request_threaded_irq(irq,                     top_half,                     thread_fn,                     IRQF_ONESHOT,                     "uart",                     dev);

现在很多新驱动结构已经变成：

IRQ快速ACK   ↓IRQ Thread   ↓workqueue   ↓协议处理

这种结构虽然上下文切换更多，但逻辑更清晰，也更符合 Linux 近年来“线程化、可抢占、实时化”的演进方向。