LWN：tasklet要被终结了！

关注了就能看到更多这么棒的文章哦～

The end of tasklets

By Jonathan Corbet
February 5, 2024
Gemini translation
https://lwn.net/Articles/960041/

在内核开发中，常见的困难在于控制 何时 让特定的任务完成。内核代码经常在一些动作（例如休眠或调用文件系统）无法进行的环境中执行。虽然可能执行其他动作，但可能会妨碍内核及时执行更重要的任务。内核社区开发了许多延迟执行的机制，旨在确保每一个任务都在正确的时间得到处理。其中一个机制 tasklet 已经有很多年都被考虑移除了，可能在不久的将来就会落实。

延迟执行经常有必要的一个环境就是中断处理程序（interrupt handler）。中断会把 CPU 从当时正在执行的任何任务中打断，要求必须尽快地处理中断代码；在中断处理程序中甚至不可能休眠。因此，中断处理程序通常仅记录需要执行的操作，然后安排在更宽松的环境中执行实际工作。这种延后执行措施有多种选项可以实现：

• 线程中断处理程序（Threaded interrupt handler） 。这种机制源于实时代码树，在 2009 年的 2.6.30 版本中合并到内核；它会导致驱动程序的大部分中断处理程序在一个单独的内核线程中运行。线程处理程序由于在进程环境中运行，因此允许休眠；如有需要的话，系统管理员还可以调整它们的优先级。
  

• 工作队列 最初 添加 在 2.5 开发系列中，从那时起得到了很大的增强。驱动程序可以创建一个 work，其中包含一个函数指针和一些数据，并将其提交到工作队列中。在未来的某个时间，该函数将使用提供的数据来得到调用；同样，此调用将在进程环境中发生。还有各种具备不同性能特性的工作队列，如有需要，任何一个子系统都可以创建它们自己的私有工作队列。
  

• 软件中断（或“下半部分”） 这种机制是内核中最古老的机制之一；它从早期的 Unix 系统中获得了灵感。软件中断是一个专用的处理程序，通常在硬件中断完成之后或返回到用户空间之前，在原子上下文中运行。多年来人们一直希望移除此机制，因为它会在内核中产生意外的延迟，但它现在仍然存在；添加一个新的（直接）软件中断的使用代码会遇到很大的阻力。有关软件中断的更多信息，请参阅 LWN 相关文章。
  

• Tasklet ，与工作队列一样，tasklet 是安排在未来某个时间调用函数的一种方法。目前，tasklet 函数将通过软件中断进行调用，并在原子上下文中运行。Tasklet 从 2.3 开发系列就有了；多年来，它们也被列入淘汰行列 很多年了，但迄今为止还没能达到目的。
  

线程中断处理程序和工作队列被认为是现代内核代码中延迟工作的首选机制，但其他 API 被证明很难被逐步淘汰。特别是 tasklet，它们保留下来是因为它们提供的延迟比工作队列小，由于工作队列必须通过 CPU 调度程序，因此执行延迟 work 可能需要更长的时间。

最近，Mikulas Patocka 在 tasklet API 中遇到了问题。Tasklet 由 struct tasklet_struct 定义，其中包含回调函数的地址和相关信息。tasklet 子系统需要能够操作该结构，并且可以在 tasklet 函数完成执行并返回后这样做。如果 tasklet 函数本身想释放该结构，这可能会导致问题，例如对于不会再次调用的单次 tasklet。tasklet 子系统可能会转而写入一个已被释放并分配用于其他用途的结构，谁都知道将导致不良后果。

Patocka 试图通过添加一个新的“单次（one-shot）”tasklet 变体来修复这个问题，在其中 tasklet 子系统会承诺在 tasklet 自己运行后不去动 tasklet_struct 结构。然而，Linus Torvalds 不喜欢这个补丁；他说，tasklet 不应该以这种方式使用。他说，工作队列设计得更好，更适合这种用例 — 除了它们可能引入的额外延迟。所以，他建议，正确的方法可能是引入一种新类型的工作队列：

我认为，如果我们引入一个更像 tasklet（因为它在软中断环境中运行）的工作队列，但没有 tasklet 的接口设计上的错误，那么许多现有的工作队列用户可能会认为这正是他们想要的。

工作队列维护者 Tejun Heo 按照这个思路执行了；从而得到 一组补丁 来添加了一种新的工作队列类型 WQ_BH ，它具有 Torvalds 所描述的语义。提交到 WQ_BH 工作队列的 work 将在同一个 CPU 上的原子上下文中快速运行。

有趣的是，这些 work 现在由 tasklet 运行，暂时是这样。由于担心 WQ_BH work 与现有 tasklet 之间优先级反转的问题，Heo 选择让 tasklet 子系统来控制。然而，该补丁系列将许多 tasklet 用户转换为了新的工作队列类型，而且很明显计划最终把其他所有地方都转换掉。这可能需要一段时间；内核中有超过 500 个 tasklet 使用位置。不过，一旦完成转换，就有可能直接从软件中断来运行 WQ_BH 工作队列，并完全移除 tasklet API。

当然，当前的实现中仍然保留了软件中断；移除该子系统将是另一项工作。Sebastian Andrzej Siewior 抱怨 使用软件中断的情况，他更愿意看到 tasklet 用户迁移到线程中断处理程序或常规的工作队列。但是，正如 Heo 回答 的那样，在需要最短延迟的情况下没法这样做。似乎总会有一个不需要调度的延迟工作机制，无论实时开发者多么不乐意看到。

Heo 将该补丁系列 标记 为针对 6.9 内核版本，这意味着它需要在 3 月中旬的合并窗口准备就绪。对于像这样的重大新特性来说，这相对算是比较快的了，但它使用一个已建立良好的内核 API 来淘汰开发人员多年来一直想摆脱的一个子系统。因此，这项特殊工作有可能不会被推迟到下一个内核周期。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～