LWN：关于realtime patch的一次问答！

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

A Q&A about the realtime patches

By Jake Edge
July 18, 2023
EOSS
ChatGPT assisted translation
https://lwn.net/Articles/938236/

在 2023 年实时 Linux 峰会上，Thomas Gleixner 回答了关于内核实时特性、其现状以及 Real-Time Linux 项目未来计划的问题。这次交流被标榜为“关于 PREEMPT_RT 的问答环节”，但是预先提示：“只讨论除了 printk()和文档之外的任何问题”。不出所料，最初的两个问题就是关于这两方面内容的，但还有许多其他问题和回答。峰会是跟首届 Embedded Open Source Summit 一起在六月底于捷克布拉格举行。

Documentation and printk()

在会议开始时，Steven Rostedt 忍不住问：“文档又怎么了？” Gleixner 听到后大笑，“很多问题”，他说。对于 realtime Linux 来说，文档的最大问题是“基本没有文档”。他对 printk() 也预先提及，是因为通常人们会问 printk 相关工作“什么时候完成？”，但这取决于“水晶球”（译者注：说不清）。对于“为什么 printk()是个大麻烦”的技术方面的讨论，他很乐意回答。

[Thomas Gleixner]

然后他进入了他的第二张（也是最后一张）幻灯片：“有问题吗？”，引发了观众的大笑。接下来，Tim Bird 问了下一个问题，不可避免地是第二个“不希望提及”的主题：“如果你不使用串口控制台，那么是否可以使用 printk()？” Gleixner 说：“不可以…或者应该说，有时候可以。”除了使用控制台外，printk() 的核心逻辑还存在一些问题，使其无法与实时补丁配合使用。这些问题已经修复，但使用 console 驱动程序的时候仍然存在问题。这些问题不是真正实时相关的问题，但使用实时 Linux 的配置来运行内核会表现得更加明显。

他说，printk()代码包含大量的 duct tape，这个名字特指 realtime 开发人员在内核的其他不少地方里也都遇到过的一种模式。例如，CPU hotplug 代码之前情况也差不多；每个人都知道该代码在设计上有问题。但是，没有去 fix 设计上的问题，而是不断添加更多的“duct tape”和…其他一些东西…直到“它慢慢腐烂成混凝土，但这种方法不可行”的地步。最终，“你必须下定决心重写”。

Bird 表示，他最近查看了实时补丁，注意到它们在内核中散步在各处，总共约 80 个 patch，虽然大部分与串行控制台有关，总共只有约 4000 行代码。他一直告诉人们，其中大部分现在都已上游，他们不必再打上这些 patch，这个说法“正确吗？” Gleixner 对此有一个简短的回答：“不”。

由于“printk()的一些部分缺失”，您仍无法在 mainline 内核中启用 realtime；这组 patch set 中的其他那些 patch 都是针对一些可以禁用的功能的，也就是都不是必需的。一旦线程化的 printk()补丁进入 mainline 内核，然后就可以向 Linus Torvalds 请求启用 x86 和 arm64 的实时功能了。跟 printk() 有关问题已经解决，这是由代码工作者 John Ogness 和 printk()维护者 Petr Mladek 提供的信息。“等它真的进入上游了，我才会相信”，Gleixner 说。

THP and networking

与会者问到关于透明巨页（THP, transparent huge page）相关的支持。目前，在选择 PREEMPT_RT 时，这个功能是禁用了的。提问者想知道是否有办法解决这个问题。Gleixner 表示，实时环境下需要继续去 fix THP 相关问题，欢迎提供 patch。实时项目一直专注于完成其他任务，还未着手解决 THP 这跟问题。从技术上讲，两者是可以配合在一起工作的，只是目前还不行。对于实时内核来说，THP 的迁移（migration）以及合并（coalescing）的延迟目前还是不能接受的。

与会者提到了使用 THP 降低 TLB 压力的优点，Gleixner 对此表示认可，但他表示项目需要优先考虑将补丁集的核心部分合并到 mainline 内核。其他人完全可以来做这项工作（或者雇佣咨询公司来做）；实时项目可能会在未来某个时候来开始研究这个问题，但如果其他需要该功能的人现在就开始处理，效果会更好。

与会者提出了第二个问题，他想知道在实时内核中是否可以提高软件中断的优先级。Gleixner 说优先级应该由管理员从用户空间设置，也就是基于整个系统的需求来判断。问题在于“软件中断在语义定义上是不明确的”，因此对于一个应用来说可能适用的优先级对于另一个应用来说可能完全不合适。这些中断是“借用了上下文，并且不能真正被控制”；网络开发人员曾为使用软件中断“持续十年全力捍卫”，但他们现在开始认识到需要重新考虑这个问题。

与会者表示当前网络方面对于实时进程来说应该会有问题；但 Gleixner 表示这是关于“多年来众所周知的事实”的重复抱怨。他再次想知道为什么人们只是抱怨而不是深入研究并解决问题。

另一位与会者指出，可以通过 sysfs 将 NAPI 线程切换到实时优先级。Gleixner 表示，网络开发人员目前正在转向使用线程化的 NAPI，这在实时方面解决了很多问题，但并非全部。网络代码中仍有很多 bottom-half 被禁用了，但一旦网络完全转向线程化的 NAPI，这些都可以改掉。

他将 disable local bottom-half（即 local_bh_disable()）类比为大内核锁（BKL）。尽管它是一个 per-CPU 的锁，但 local bottom-half 保护的内容没有定义清晰，就跟 BKL 一样。而且同样，移除这些调用也会导致问题，“但你无法确定原因”。

去除 BKL 的流程很有价值，因为它使得内核开发人员可以弄清楚它在整个内核中保护的内容，不过还有一个例外：TTY 层。这引发了有关 TTY 层跟 realtime 补丁的提问。原来与会者真正希望能够使用内核中所有可用的 UART 设备，但目前唯一的访问途径是通过 TTY 层。

“如果你通过 TTY，那就完了”，Gleixner 说。“祝你在 fix TTY 层的时候有好结果”，他继续说；即使给他报酬，他也不会“触碰那个问题”。如果实时进程需要串口通信，那么必须添加其他机制，因为对于实时来说，TTY 是“无法修复”的。

与会者表示，他们通过串行设备发送的数据不多，但 Gleixner 表示这并不重要；如果访问设备的唯一代码路径是通过 TTY 层，那么“你就是会有问题”。如果确实有其他用例需要采用非 TTY 的方式访问这些设备，那么可以添加其他代码路径；与会者同意他的用例跟 TTY 无关。

实际上，提问者表示他自从 Linux 1.2 时代就一直在维护一种 out-of-tree 的 UART 驱动，但它依赖于一种可能不再可用的特定芯片。Gleixner 表示，一个自从 30 年前 1.2 版发布以来就已知的问题，看起来早该通过与上游内核开发人员合作找到适当解决方案了。对于各种不同类型的奇怪设备已经有了支持，添加另一个设备应该不会造成太大问题，只要有使用场景，以及给出需要绕过 TTY 层的原因。

接下来关于把 i915（Intel 图形）驱动加回来的问题引发了 Gleixner 和许多与会者的笑声。显然，该驱动在实时内核中也被禁用了。Gleixner 表示，唯一的方法是等待目前尚在开发阶段的新驱动。当前的驱动无法 fix，而在 realtime tree 中的相关 patch“非常糟糕”；也许它们最终真可能被合并，但这会是今后的事情，并且他很怀疑它能否被内核接受。

现有 i915 驱动中的某些 lock 代码路径“完全是自制的，并且脱离了世界上合理的加锁方案”。这是正在开发新驱动的原因之一；“替代性的驱动正在开发中，你只需等待”。这是 realtime 开发人员一直试图 fix 的“内核灾难”之一。

Things to avoid

一位与会者问，除了已经提到的 TTY 层和 i915 驱动之外的需要在 realtime 补丁中避免使用的东西。Gleixner 说 i915 实际上只要使用了实时树中的“hacky patch”就可以工作，至少“在某种程度上能工作”。但应该避免从 realtime 任务中使用 TTY 层；你可以从最高优先级的任务中调用 printf()，但这可能不是最好的主意。从实时任务中进行 I/O，通常不是正确的设计。

提问者对文件系统方面提出了问题；在运行实时内核时，文件系统是否会存在问题？Gleixner 表示很长一段时间以来他没有看到文件系统方面的问题。Daniel Bristot de Oliveira 表示最近在 Btrfs 上看到了长时间的延迟，但 Gleixner 对此并不知情。实际上，其他内核开发人员总是“在他们的代码中加入不必要的 preempt_disable()”；这些问题需要被解决，开发人员必须被要求不要这样做。这是他“急需找到时间完成《Kernel Developers Guide to RT》”的原因；完成文档之后，实时开发人员就可以指给其他内核开发者来看这个文档。

但他说，文件系统基本上不会有问题，因为它们不属于实时计算的一部分；“如果你在实时任务中写入日志文件，好吧，这是你自己的选择…如果磁盘卡住了，你就等着吧”。何不使用某种内存文件系统，有人问道。Gleixner 表示这个方案可能可行，“但是，真的，不要这样做”。他说，这违反了实时相关的所有原则；这不是 Linux 特有的问题，因为所有不同的实时操作系统都会警告人们远离 write()、read()等操作。

他说，实时程序应该要么一次性地读取数据，要么真有需要不断更新数据的话可以用另一个非实时进程用大 buffer 来进行读取。如果实时任务需要连续写入数据，它应该写入一个 ring buffer，由单独的非实时任务进行写出。这是基本的 realtime 理论，不论是不是使用 Linux 都一样，他说。

有人表示有些系统需要实时处理流媒体数据，例如来自摄像头的数据；这样的处理应该怎么做？“那是一个系统设计问题”，Gleixner 说；例如，你需要一个专用的网络队列，但没有“什么通用的方法能确保它可靠”。当前的网络代码在实时方面表现不佳，但可以对系统进行一些微调，以使其能够处理高速流媒体数据。还有一些选项是可以在用户空间处理网络流量，从而避免 realtime 跟当前网络代码的一些问题。

Long journey

Bird 问及 Intel 收购 Linutronix 的事宜，Linutronix 是 Gleixner 和其他一些实时开发人员的雇主；他想知道 Intel 是否正在为实时 Linux 提供资金支持。Gleixner 说 Intel 一直通过 realtime Linux 项目来帮助资助实时工作；Intel 和 Arm 都对 realtime Linux 感兴趣，这从他们的项目成员资格上就可以反映出来。项目组织者、Linux 基金会 Dependable Embedded Systems 的副总裁 Kate Stewart 表示，Intel、Arm、TI、National Instruments、Red Hat 等公司都参与了将完整的 realtime patch set 并入 mainline 的“漫长旅程”。

Rostedt 指出，这个漫长的旅程在 2024 年就会走到第 20 个年头，但 Gleixner 表示这只是被公开的部分。该项目最早于 2004 年就发布到 Linux 内核邮件列表，但对于他来说，相关活动始于 1999 年末。这意味着从项目开始算起，他将度过 25 年的时间；“这是一段漫长的旅程，我们需要随着时间的推移来解决和改进很多问题”，尽管“能做到的总是有限的”。他曾尝试过日以继夜地工作，但发现“这并没有让过程更加高效”。

最后一个问题是关于 cyclictest 工具的作用；它是否是一个好的参考应用程序？Gleixner 表示 cyclictest 在测试方面很有用，但并不“类似于任何特定的真实应用程序”。提问者想知道是否有好的真实应用程序示例可以供 review。Gleixner 表示他不知道有没有，但 cyclictest 和其他测试/基准测试应用程序确实提供了一种基本的参考实现。然而，真实世界的应用程序具有各种需求和复杂程度。

寻找一个可供参考的实时应用程序的部分问题在于需要专门的硬件，Gleixner 说。这对于测试和基准测试实时系统是一个难点；如果没有访问相同的硬件，那么测试结果实际上是无法被复现出来的。将这样的测试集成到持续集成（CI）系统中尤其困难。有基础设施允许在其硬件上运行 CI 或其他测试的人将结果反馈给实时项目，这有助于检测和发现质量回退（regression）和其他错误。随着这个回答结束，Gleixner 指出他不再阻碍与会者前往酒吧（或其他晚间活动），2023 年实时 Linux 峰会圆满结束。

【特此感谢 LWN 的旅行赞助商 Linux 基金会为编者前往布拉格提供的支持。】

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

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

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