LWN: realtime的未来计划！

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

Preparing for the realtime future

By Jake Edge
September 9, 2020
LPC
原文来自：https://lwn.net/Articles/830660/
DeepL assisted translation.

与以往许多 Linux realtime 开发者的聚会不同，在 2020 年 Linux Plumbers Conference 虚拟会议上的微会议感觉有点不太一样。微会议的主题居然不是讨论什么时候以及如何让这个功能合入 mainline，而是用两场会议来探讨 realtime patches 进入 upstream 后会发生什么。目前还没有合入，不过很有可能在 5.10 kernel 会进行合入，所以开发者们在展望 stable realtime tree 的未来，以及与此相关的 realtime kernel 的持续集成（CI）测试计划。

Stable trees

由于 realtime patch set 将在 "any release now "完全进入 upstream，因此需要为 realtime stable （RT-stable）内核后续的工作制定一下计划，Mark Brown 在会议开始时如此介绍道。目前，每一个长期支持（LTS， long-term support）稳定内核版本都有对应的 RT-stable kernel 一直维护着；realtime patch set 会 backport 到这些 kernel。但一旦 patch 进入 mainline，就不会再需要 backport 到新的 realtime tree 上了。

他想知道，如果人们想要实时功能，是否应该简单地告诉他们使用 mainline stable kernel 就好了。这样的话，那么在 stable kernel 中出现的 realtime 性能降低问题都需要作为 bug 来解决，而这些 fix 也需要被 stable kernel 的 maintainer 接受并合入。realtime 开发者也需要帮助解决在将 fix 代码 backport 到 stable kernel 中所产生的合并冲突。

测试是另一个需要改变的领域。尤其是，realtime performance 需要在 stable release 发布过程进行测试来覆盖。现在，Greg Kroah-Hartman 主要将 stable kernel 上特定的使用场景和工作场景的测试外包给那些有兴趣确保这些东西继续良好运行的人。realtime performance 的测试将需要成为其中的一部分。

Steven Rostedt 是由 Clark Williams 推举来负责进行测试的。Rostedt 也表示了意愿，他指出自己过去也做过这种事情。他说，将实时测试自动化是非常有必要的。理想情况下，每个新的稳定内核都会被自动下载、构建，并通过一系列的 realtime 特定测试来验证。Brown 很开心地提醒，微会议的下一个环节就是关于 CI 测试的。他还表示，测试 stable kernel 的候选版本要比测试标准 kernel release 更有意义，可以在用户拿到手之前发现问题。

这时 Kroah-Hartman 突然冒出一句话说，实时内核并没有任何独特之处，"你们和大家一样，所有人都是 special 的"。他将根据需要将 regression fix 合入代码 tree 中，并可以提供各种方式来触发实时内核的构建和测试。Rostedt 同意，从稳定维护者的角度来看，realtime 并没有任何特殊之处，但实时开发者需要想办法实现测试的自动化。

Brown 说，目前是由 RT-stable 维护者将 patch 打到稳定树上，并手动测试编译出来的内核。Kroah-Hartman 建议将实时测试加入到 KernelCI 基础架构中，这样每当发布 stable candidate 的时候它就会自动得到构建和测试。Rostedt 说，目前，实时补丁并没有马上合并到稳定树中，因为 stable kernel 上的改动经常会与 realtime patch 有合并冲突，但一旦全部 upstream 之后这就不是问题了。

Kroah-Hartman 说，进入 KernelCI "非常容易"。但 Brown 指出，realtime 需要做的测试种类与内核其他部分不同。Williams 说，realtime test 更关注性能标准而不是功能是否完好。但 Kroah-Hartman 说，KernelCI 现在已经有了功能测试和性能测试，所以加入 realtime 测试应该没有什么问题。Brown 表示同意，但他说，需要有人把测试移植进去先。

Rostedt 举例说，他运行一个测试，在多个内核上反复构建内核，同时还多次运行 hackbench。所有这些都是在一个周末内运行完毕的，同时他用 realtime task 来运行 cyclictest 并记录它们的延迟，确保没有任何大于 50µs 的延迟。这种测试只需要打包并自动调用，这样就可以由各种机器人来运行。

另一个问题是，realtime 是否应该有自己独立的 staging tree（暂存树）来验证新功能，比如新增的 futex()接口。他问道，是否应该将当前的 RT-stable 树变成新特性的 "testing playground"。如果这些特性被认为对 mainline 有用，那么它们也可以被 backport 到 stable kernel 中。但 Williams 想知道是否是时候让这个 code tree "重出江湖，不被冷落 "了。他看到 "RT-next"对于开发情况下的价值，但不认为在早期 kernel 系列中支持这些特性会有很好的效果。虽然在讨论中没有提到，但那些改变也可能会违反稳定内核中只允许修复实际 bug 的规则。

Rostedt 还是比较同意 Williams 的观点的，但他也指出 API 设计存在一种 "catch-22"问题，即如果没有用户测试，就无法得到一个好的 API，但如果没有一个好的 API，又很难让用户去测试。Williams 也认为这里面有问题，但并不认为从 RT-next 进行 backport 就真的能有助于解决这个问题，相反，这很可能只会给 realtime 开发者带来头痛的问题。他说，测试人员可以自己使用 RT-next 来进行编译。

Rostedt 说，实时性进入 mainline 后，需要确保有一个团队关注它的发展。这个团队将确保实时性不会在 stable kernel 中被破坏。Williams 问是否会指定一个人来处理实时 bug，但 Rostedt 认为，再一次强调，一旦到了 upstream，realtime 功能并没有什么特别的地方。人们会以通常的方式报告 bug，stable maintainer 会根据需要将 bug 转给 realtime 开发者。

Sasha Levin 说，现在是让自动化测试到位的好时机，在功能进入 mainline 再做这一点就更加困难。现在的大多数 RT-stable patch 都可以直接达到 stable candidate 上，Williams 说，所以这些可以用来开始制定自动化测试策略。计划很快就形成了，以 Daniel Wagner 的 4.4-rt tree 的脚本为起点，尝试自动在 stable candidate 上合入 realtime patch，如果成功的话，那么测试就可以直接启动了，看看在生成的内核中是否有任何 realtime 特有的问题。一旦 realtime 版本进入 mainline，这个自动合入的步骤就会被取消。

Continuous integration

随着第一场会议的结束，会议转入了由 Bastian Germann 主持的 mainline 上对 realtime 进行 CI 的研究。他指出，目前已经有一些针对 realtime 的自动化测试，尽管显然多数人并不了解这个系统：CI-RT system。它是一个基于 Jenkins 的 CI 系统，是为测试 realtime kernel 的需求而定制的。在 Linutronix（Germann 所在的公司）已知有一个实验室在用 Linux Foundation Real-Time Linux project 的成员公司捐赠的硬件来运行这组测试。

realtime 开发者可以通过 Git 仓库在 CI-RT 中配置要进行的测试。测试的结果会在 CI-RT 网站上给出报告，也会通过电子邮件发给正在运行测试的开发者。内核是在构建服务器上构建的，然后在目标硬件上启动，这作为第一级测试。之后，系统运行的测试有点类似于 Rostedt 之前所描述的。它分别在空闲和繁忙的系统上使用 cyclictest 进行测试，繁忙的系统是由 hackbench 加上其他进程产生的，比如使用递归 grep 来产生大量的中断，他说。然后会记录系统的 cyclictest 测试结果。

他说，一旦 realtime 进入主线，CI-RT 系统就可以照样使用，只需更改一下正在使用的 Git 代码来源就好。除了 mainline 本身，还有一些其他代码 tree 应该进行测试，包括一些在上一个讲座中提到的 tree。mainline 和 linux-next 的当前 release candidate 就应该得到测试，stable kernel 也应该得到测试，包括大家讨论过的这些 tree 的 release candidate。每个代码 tree 的测试频率和测试持续时间都需要确定下来，比如他建议 linux-next 可以每天晚上测试 8 小时。

他说，目前还没有其他 CI 系统运行 realtime 测试，尽管 Brown 希望在 KernelCI 中来支持 realtime 测试。Germann 说，一旦 realtime kernel 被合并，应该会有更多的实验室对其进行测试。这将覆盖更多的硬件，以及提高内核开发者对 realtime 的认识。为了实现这一点，实时项目需要支持其他 CI 系统；KernelCI 支持正在进行中，但他问大家是否有其他测试系统或 CI 系统需要支持 realtime test。

大家对如何自动处理 Git tag 的签名问题进行了一些讨论，但最终认为这个事情并不可取，之后 Nikolai Kondrashov 建议 CI-RT 将其报告发送给 KernelCI。他和其他人正在努力将测试结果收集并统一到一个通用数据库（https://foundation.kernelci.org/blog/2020/08/21/introducing-common-reporting/ ）中。

Germann 询问了可以收集的数据种类。理想情况下，CI-RT 希望呈现的不仅仅是 "pass"或 "fail"，还将包括做出该决定所依据的 latency 测量值。Kondrashov 说目前该模式只提供了一种报告测试状态的方法，但有一种方法可以附加额外的数据。该项目正试图与各种测试系统的开发者和操作者合作，以确定应该在 JSON 模式中添加哪些附加信息。Veronika Kabatova 提到，Red Hat Continuous Kernel Integration(CKI)项目愿意开始进行 realtime test，也会免费集成到 KernelCI 的统一报告中。

Mel Gorman 说，SUSE 也运行着一个基于 Jenkins 的 CI 系统，它使用一些 realtime test 作为其性能测试的一部分。他开发的 MMTests 中有一些建议配置，可以用来帮助进行 realtime test。这些可以与 hackbench ，或内核编译运行及 cyclictest 结合起来，来确定是否能满足 realtime latency requirement。他说，将 realtime 测试集成到其他一些现有测试客户端框架（如 MMTests）中是更有意义的，而不是试图针对每个不同的 CI 系统制作多个版本的测试。

各种 CI 工作讨论往往聚集在 freenode 上的#kernelci 频道或 automated-testing@lists.yoctoproject.org 邮件列表中。与会者计划与这些小组合作，确定正确的前进道路，以便为 realtime kernel 进行更多的 CI 测试。一旦 realtime patch 最终被合并，CI-RT 系统应该可以为今后的 CI 测试提供一个良好的起点。

如上所述，这些会议的重点与过去的大多数会议非常不同。realtime patch set 的最终合并将对此项目与内核其他部分和整个内核生态系统的交互方式产生重大影响。重要的是要提前制定出 stable tree 维护的计划，以及采用什么方式来确保该功能在快速发展的 mainline 中保持正常工作。微会议对这两方面都有帮助。

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

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

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