LWN：Arm Linux 内核的第一次Linaro 论坛！

最新推荐文章于 2024-10-25 07:00:00 发布

LinuxNews搬运工

最新推荐文章于 2024-10-25 07:00:00 发布

阅读量190

点赞数

文章标签： arm开发 linux 运维服务器

原文链接：https://mp.weixin.qq.com/s?__biz=Mzg2MjE0NDE5OA==&mid=2247488441&idx=1&sn=56d215e109d62249b02747b979d10ec4&chksm=cf11b036f9b6d7f675a2c5c522e6b2103088bcd65737a7303533bd9ec68bbd4490c358b29530&scene=126&sessionid=0

版权

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

The first Linaro Forum for Arm Linux kernel topics

April 9, 2024

This article was contributed by Tom Gall, Bill Fletcher, and Arnd Bergmann
ChatGLM translation
https://lwn.net/Articles/969031/

在 2 月 20 日，Linaro举行了旨在成为针对 Arm 相关内核开发的社区的定期 Linux 内核论坛的首次聚会。这次聚会计划在大约每两周举行一次，时间是在合并窗口开启前和当前正在开发的内核版本发布前。第一次聚会讨论的主题包括为低端嵌入式系统准备 64 位 Arm 内核、内存错误（memory errors）和 Compute Express Link (CXL)、devlink 目标以及调度器的集成。

这个论坛通常采用“展示和讲述”的形式，让人们分享他们的计划，提出当前存在的问题，并推进针对未来内核版本的讨论想法。理想情况下，这将有助于加强协调，找到志趣相投的开发者，并鼓励参与。会议是公开的，并且会被记录下来；这些笔记旨在传达会议的内容。

会议议程、Zoom 会议链接和录音链接可以在这个页面上找到。

会议专注于帮助 Arm 内核社区解决生态系统中的 Linux 上游问题。人们认识到，这需要社区的大力支持。认真策划并且让正确的人参与会议很重要，尤其是为了避免那种“随意询问维护者”的会议。目标不是要求标记或把一个补丁集排上优先级，而是与他人和社区分享人们希望在下一个周期中关注的内容。

为低端嵌入式系统准备 Arm64 内核

由 Arnd Bergmann 主导。

Bergmann 询问了现在 Arm64 开始在低端、嵌入式系统中取代 32 位 Armv7 CPU 时，内核需要进行哪些更改。这些设备通常是占据了大众市场的，如相机 SoC，通常会拥有少于 128MB 的 RAM；它们以前是 Armv7 的领域。在使用 32 位系统时，我们根本不需要优化内核；现在迫切需要的是缩小内核的大小并消除开销。由于嵌入式系统现在运行多个虚拟机，对单个系统内存消耗的优化也变得非常重要。我们能将内核和系统做到多小？

Bergmann 讲述了几种选项以及初步的结果，首先就是关闭功能，同时仍然能够启动 Debian 镜像并拥有正常的文件系统和网络连接；这使 64 位内核的大小降至 7MB。40MB 也是可以放置一个完整系统的。然后焦点转移到缩小用户空间。32 位用户空间节省的内存比在内核中能做到的要多得多，但与 32 位内核相比，内核代码、数据和堆的开销仍然有两倍。

探索的可能减少开销的方法包括：

CONFIG_SMP ，如果只启用单个 CPU 核心，可以节省 1-3MB 的 RAM。
Execute-In-Place (XIP) 可以通过将所有文本和只读数据放入闪存来节省 RAM（在一个示例案例中节省了高达 5MB ）。
XIP 在运行时打补丁（run-time patching）存在问题。现代 CPU 特性在运行时被检测到（并根据加载的内核进行相应的运行时补丁修改），但我们应该重新考虑这一策略，以构建一个只在新 CPU 上运行的小型内核。
有一个针对 32 位 CPU 的死代码消除补丁(CONFIG_LD_DEAD_CODE_DATA_ELIMINATION)，但并没有造成太大的差异。这里可能有更多的潜力可挖，而且几乎没有负面影响。

内存错误和 Compute Express Link (CXL)

由 Jonathan Cameron 主导。

ACPI/APEI: 发送正确的 SIGBUS si_code ：Cameron 提出了一个内存错误报告的问题。内存错误产生一个 ACPI 事件；如果报告的错误在用户空间进程中，期望是包含错误的过程将被杀死。不幸的是，由于 ACPI 事件报告了错误的错误类型，这个做法目前不起作用。因此，目前检测到的用户空间进程中的内存故障并没有导致该进程被杀死。这是需要解决的问题。
针对差异化可靠性（differentiated reliability）的内存擦除（memory scrub）控制 ：这也跟 memory-error 的上报有关。memory scrub 这种动作会需要定期检查 ECC mmeory 来确认是否有错误。目的是把避免可以由 ECC 纠正的错误演变成不可纠正的错误。通常这个动作是由内存控制器（memory controller）自主完成的，甚至可能是由内存条（memory DIMM）自己来完成的（在 DDR5 里面实现了 Error Check and Scrub, ECS）。无论是否可以被纠正的错误，都会被报出来。

Cameron 还提出了 CXL 情况下用户空间控制内存擦除的需求，因为固件无法在热插拔设备的情况下进行配置。有一个RFC v6 版本的提案。还有谁关心这个问题？我们能将它做到有多通用？除了服务器，还有哪些细分市场可能会关心这一点？有一个提议保护的擦除控制系统就带有 ABI，这是否是正确的方向？

启动后的 NUMA 域 ：目前 Arm64 假设所有内存热插拔都在已知的 NUMA 节点中进行。相比之下，x86 并不假设这一点，但它有一个特定于架构的解决方案来关联内存热插拔和 NUMA 节点。CXL 内存是热插拔的，并且有一个潜在假设我们为每个 CXL 固定内存窗口结构（CFMWS）内存窗口声明一个 NUMA 节点。我们需要知道哪些 NUMA 节点与热插拔事件相关联。目前没有人愿意投入将需要解决动态 NUMA 节点创建所需的（相当大的）努力。作为一种变通方案，我们可以重新解析 CXL 早期发现表（CEDT）并进行查找。这种做法是否太过于粗糙了？

具有广泛影响的配置选项 ：CXL 具有一些内核特性，其用户空间接口如果被误用，可能会通过例如移除所有人的内存访问权限，而使整个机架甚至数据中心陷入瘫痪。为了减轻这种风险，将会实施安全措施，但安全漏洞仍然可能导致整个机架被破坏。因此，社区对接受这些特性表示了反对。

这些接口在必要时应该只连接到主板管理控制器（BMC）或布线管理器（fabric manager）。这个问题也适用于管理组件传输协议（MCTP）栈。我们如何防止人们在使用这些在通用系统中配置的选项时伤害自己？解决方案包括将所有这些特性都置于 CONFIG_(I_AM_A_)BMC 选项后面，或者使用内核污染，这在 CXL 的其他地方已经使用。其他人还有别的建议吗？

fw_devlink 的当前计划

由 Saravana Kannan 主导。

Kannan 计划进行许多待办事项，包括在 devicetree 架构中添加 post-init-suppliers。一个 devicetree 链接（devlink）应该确保 "供应商（supplier）" 设备和其 "消费者（consumer）" 设备之间的正确挂起/恢复（suspend/resume）和关闭顺序。consumer 设备在 supplier 绑定到驱动程序之前不会进行 probe，并且在 supplier 被解除绑定（unbound）之前也会被解除（unbound）。

不幸的是，在 devicetree 中供应商和消费者之间存在循环依赖；添加 post-init-suppliers 属性是为了提供一种方式，让固件 devlink 接口或任何内核能够打破这种循环。这是为了实现可靠的探测和挂起/恢复操作，最终目标是提高稳定性和可靠性，并改善运行时的电源管理。此外，如果供应商被强制解绑，消费者不一定能被正确清理，除非它是一个带有驱动程序的总线设备。在这项工作中也将修复一些边缘情况。

另一个目标是添加对 "class" 设备的 devlink 支持。Devlink 是一个驱动核心特性，其中设备可以声明 "在我供应商完成 probe 之前不要 probe 我"。目前，class 设备不会被探测，我们只是添加它们。目前允许将 class 设备作为供应商添加。可能存在一些奇怪的 probe 行为。其中一些细微差别比如 class 设备何时 "ready" 有关。

最后，还有对 clock-framework 同步状态（sync-state）的支持。这一点在 2023 年 Linux Plumbers Conference 上讨论过。有一些共识，清理 Kannan 一年多前的补丁系列并解决指出的问题。他预计会将其作为 RFC 或更新的补丁集发送出去。

调度器上的系统压力

由 Vincent Guittot 主导。

这项工作已经在 OSPM 和 LPC 展示过。它的目标是统一调度器对 CPU 计算能力的看法以及它如何映射到实际的 CPU 频率上。

arch_scale_*() 是针对特定架构的函数，允许架构相关的代码向调度器报告某些特定的行为。例如， arch_scale_cpu_capacity() 报告 CPU 的最大计算能力。默认函数返回相同的值 - 对于所有 CPU 都是 1024 - 这对于 SMP 系统来说是可以的，但如果 CPU 具有不同的计算能力，例如 big.LITTLE 或异构系统，架构可以提供自己的版本。类似地， arch_scale_freq_capacity() 根据当前频率报告 CPU 的当前计算能力。有了 arch_scale_cpu_capacity() 和 arch_scale_freq_capacity() ，调度器就知道了 CPU 的计算能力，并可以将其与其他 CPU 进行比较，从而选择一个任务。然而，在某些配置下，当核心的最大频率在启动或运行时发生变化时，可能会出现一些不一致。

将所有 arch_scale_*() 函数整合的工作被分为三个部分。第一部分，包括 arch_scale_cpu_capacity() 和 arch_scale_req_ref() ，已经在 6.8 中合并。它引发了一些质量回归问题，但现在已经修复。第二部分引入了 arch_scale_hw_pressure() 和 cpufreq_get_pressure() 。这正在邮件列表上讨论，有一个新的版本（v6）。

下一个任务将是 6.10 中的新 arch_scale_cpu_capped() 。当用户空间对 CPU 的最大频率进行了限制时，我们希望将此作为 CPU 的新的最大计算能力，而不是进行某种估计或最佳努力决策。最终目标是更好地将用户空间限制考虑进调度器中。Guittot 对此很感兴趣，希望能得到任何反馈。