2. 工作队列与软中断/tasklet的对比：执行上下文、可睡眠性、并发度、使用场景分析
在 Linux 内核中，软中断（SoftIRQ）、tasklet 和工作队列（Workqueue）是三种最常用的延迟机制。它们都用于将非紧急任务推迟到稍后执行，但在执行上下文、可睡眠性、并发模型和适用场景上存在本质差异。理解这些差异是正确选择延迟机制的前提。
核心原则： 中断上下文（软中断/tasklet）追求极低延迟和原子性，但禁止睡眠；进程上下文（工作队列）允许睡眠和复杂操作，但调度延迟相对较高。选择哪种机制，取决于你的任务是否需要“等待”。
2.1 执行上下文对比
执行上下文决定了代码能够调用哪些内核 API、是否允许抢占、以及能否触发调度。
| 特性 | 软中断 (SoftIRQ) | tasklet | 工作队列 (Workqueue) |
|---|---|---|---|
| 执行上下文 | 中断上下文（硬中断关闭或开启） | 中断上下文（软中断上下文） | 进程上下文（内核线程） |
| 可睡眠性 | ❌ 禁止睡眠 | ❌ 禁止睡眠 | ✅ 允许睡眠 |
| 可抢占性 | 不可抢占（除非开启 PREEMPT_RT） | 不可抢占 | 可被抢占（普通进程调度） |
| 持有锁类型 | spinlock（自旋锁） | spinlock（自旋锁） | mutex（互斥锁）/ spinlock |
| 中断状态 | 可能处于硬中断关闭状态 | 软中断开启，硬中断可能关闭 | 完全可中断 |
关键区别： 工作队列运行在进程上下文，这意味着它可以调用
msleep()、wait_for_completion()、copy_from_user() 等可能引起调度的函数。而软中断和 tasklet 中调用这些函数会导致内核崩溃（BUG: scheduling while atomic）。
2.2 可睡眠性分析
可睡眠性是区分工作队列与其他延迟机制的最重要指标。为什么软中断和 tasklet 不能睡眠？
- 软中断/tasklet 运行在中断上下文中：它们没有自己的进程控制块（task_struct），不参与调度器管理。如果睡眠，调度器无法找到该“进程”来唤醒它。
- 软中断/tasklet 可能持有 spinlock：spinlock 要求持有者不能睡眠，否则会导致死锁。
- 工作队列拥有独立的内核线程：每个工作队列背后都有一个或多个内核线程（kworker），这些线程有完整的进程上下文，可以像普通进程一样被调度、睡眠和唤醒。
常见错误： 在 tasklet 或软中断中调用
kmalloc(GFP_KERNEL) 也可能触发睡眠（内存回收时）。必须使用 GFP_ATOMIC 标志。而在工作队列中，可以安全使用 GFP_KERNEL。
2.3 并发度对比
并发度决定了同一类型的延迟任务能否在多个 CPU 上同时执行。
| 机制 | 并发模型 | 同一类型实例的并发 | CPU 亲和性 |
|---|---|---|---|
| 软中断 | 每个 CPU 独立运行 | ✅ 可在多个 CPU 上同时执行同一软中断 | 绑定到触发 CPU |
| tasklet | 串行化执行 | ❌ 同一 tasklet 在同一时刻只能在一个 CPU 上执行 | 绑定到调度 CPU |
| 工作队列 (默认) | 共享线程池 | ✅ 可在多个 CPU 上并行执行不同工作项 | 可设置 CPU 掩码 |
| 工作队列 (WQ_UNBOUND) | 不绑定到特定 CPU | ✅ 完全并行，可迁移 | 无固定 CPU |
并发陷阱： tasklet 的串行化特性虽然简化了数据同步，但也限制了吞吐量。如果多个 CPU 频繁触发同一 tasklet，它们必须等待前一个实例完成。工作队列的并发度更高，但需要开发者自行处理并发访问保护。
2.4 使用场景分析
根据上述差异，可以总结出每种机制的最佳适用场景：
软中断 (SoftIRQ) 适用场景
- 极高频率的重复性任务：如网络数据包接收（NET_RX_SOFTIRQ）、定时器（TIMER_SOFTIRQ）。
- 对延迟极度敏感：要求从触发到执行的时间尽可能短。
- 任务执行时间极短：通常在微秒级，不能有阻塞操作。
- 需要每个 CPU 独立处理：如 per-CPU 统计计数。
tasklet 适用场景
- 中等频率的 I/O 完成处理：如 DMA 传输完成后的回调。
- 需要串行化访问共享资源：利用 tasklet 的串行特性避免加锁。
- 任务执行时间较短：通常在几十到几百微秒。
- 不需要睡眠：所有操作都是原子性的。
工作队列 (Workqueue) 适用场景
- 需要睡眠的任务：如等待硬件就绪、访问用户空间内存。
- 执行时间较长的任务：毫秒级甚至更长的操作。
- 需要持有 mutex 锁：复杂的资源访问控制。
- 需要绑定到特定 CPU：利用 CPU 亲和性优化缓存性能。
- 需要延迟执行或周期性执行：结合
schedule_delayed_work()。
经验法则： 如果任务执行时间超过 100 微秒，或者需要调用任何可能睡眠的函数，请使用工作队列。如果任务在几十微秒内且不能睡眠，使用 tasklet。只有对性能有极致要求且频率极高的场景才考虑直接使用软中断。
2.5 选择决策流程
以下决策树可以帮助你在开发中快速选择合适的延迟机制：
2.6 性能开销对比
不同机制的调度延迟和上下文切换开销也有显著差异：
| 指标 | 软中断 | tasklet | 工作队列 (per-CPU) | 工作队列 (unbound) |
|---|---|---|---|---|
| 调度延迟 | < 1μs | 1-5μs | 10-100μs | 50-500μs |
| 上下文切换 | 无（中断上下文） | 无（中断上下文） | 有（进程切换） | 有（可能跨 CPU） |
| 内存开销 | 极低（静态分配） | 低（每个 tasklet 约 40 字节） | 中（每个 worker 线程栈 8KB+） | 中高（线程池管理） |
| 可扩展性 | 高（per-CPU 设计） | 低（串行化瓶颈） | 高（多线程并行） | 高（动态调度） |
性能取舍： 工作队列的调度延迟虽然比软中断高 1-2 个数量级，但对于大多数设备驱动和内核服务来说，100μs 级别的延迟完全可以接受。只有在网络栈、块设备层等对延迟极度敏感的核心路径上，才需要坚持使用软中断。
2.7 总结
工作队列、软中断和 tasklet 各有其设计目标和适用边界。选择时遵循以下原则：
- 先看能否睡眠：需要睡眠 → 工作队列；不需要 → 继续判断。
- 再看执行时间：超过 100μs → 工作队列；短任务 → 继续判断。
- 最后看并发需求：需要串行化 → tasklet；需要高并发 → 软中断。
- 默认选择：在大多数驱动开发场景中，工作队列是“最安全”的选择，因为它提供了最大的灵活性。