泰晓资讯·1 月 / 第二期 / 2024

“泰晓资讯”，广泛报道 “Linux/开源” 业界资讯。欢迎广大读者投递相关资讯来源和素材，本站将进一步收集整理后发布给大家。

Linux 内核最新消息

上周末，针对 Linux 6.8 的合并工作一度陷入了混乱，由于 Linus Torvalds 居住地所在的俄勒冈州（Oregon）波特兰（Portland）地区遭受到一场严重的冬季风暴袭击，并因此失去了互联网接入和电力供应。这导致 Linus 先生有将近五天无法处理 Linux 6.8 合并窗口的 Git 合并工作，不过所庆幸的是在本周三 Linus 开始恢复工作了。

Linus Torvalds 在 social.kernel.org 的最新一篇帖子中表示，截至本周三的 17 日他已经处于 “在家度假” 状态有五天了，供电公司有希望在当天晚间之前恢复供电，而他在前一天也曾有类似的承诺，但似乎并没有兑现。

但好消息是，就在 17 日下午三点左右，我们终于又在 Linux Git 中看到他的提交记录，看上去他已经恢复了 v6.8 的合并工作。Linux 6.8 带来了许多新功能。如果原来的计划得以维持，Linux 6.8-rc1 应该在本周日发布，以标志着合并窗口的关闭，而稳定的 v6.8 内核应该在 3 月中旬发布。

https://www.kernel.org/ updated by 2024/1/18

关键词: Linux

Torvalds 在 6.8 中发现一个严重的性能衰退问题

Prior to Linus Torvalds’ Internet and electricity being knocked out by a snow storm and thus impacting the Linux 6.8 merge window, his weekend was already in rough shape due to encountering a performance regression with new Linux 6.8 code that was causing his Linux kernel builds to be as twice as long as with previous kernels. An AMD Linux engineer was able to reproduce the regression and with upstream developers there is now a believed fix for this issue in the latest scheduler code.

就在 Linus Torvalds 因互联网和电力被暴风雪摧毁并不得不中断 Linux 6.8 合并窗口工作之前，他已经遭受到另外一个问题的困扰，这是因为他遇到了一个新的导致 Linux 6.8 代码性能下降的问题，这个问题导致他的 Linux 内核构建时间延长为以前的两倍（完整的内核构建从 22 秒变为 44 秒）。所幸的是来自 AMD 的 Linux 工程师重现了这个问题，并且与其他上游开发人员一起，在最新的调度程序代码中解决了此问题。

当 Linus Torvalds 报告了 Linux 6.8 中的这个涉及调度程序更改引入的重大性能回归问题时，通过对提交历史的二分查找，相关开发人员并没有很快搞清楚是什么导致了这个问题。在随后的讨论中，来自 AMD 的 Wyes Karny 报告说，他也可以重现这个问题。Wyes 没有像 Torvalds 那样使用高端的 AMD Ryzen Threadripper，而是使用普通的 AMD Ryzen 5600G 台式机。他提出的一个重要发现是，只有在从 BIOS 禁用 ACPI CPPC 并将 ACPI CPUFreq 与 Schedutil 调控器一起使用时，才会重现此情况。

大多数 AMD Zen 2 和更新的系统都支持 ACPI CPPC，因此在 Ryzen 系统上运行的现代内核通常使用新的 AMD P-State 驱动程序。但对于某些 Zen 2 / Zen 3 及更早版本（或在 BIOS 中禁用了 CPPC 的系统），仍会使用 CPUFreq 驱动程序，这时通常情况下默认的 CPU 频率调控器为 “Schedutil”。

基于该发现，从邮件列表中找出了一个补丁，通过针对该问题的讨论和分析，最后，Vincent Guittot 相信他已经找到了解决该性能衰退问题的办法，而 Wyes 基于该修改测试也验证了这个问题。

Guittot 现在已经针对这个问题发送了修复补丁，他在补丁中解释如下：

“When frequency invariance is not enabled, get_capacity_ref_freq(policy) returns the current frequency and the performance margin applied by map_util_perf(), enabled the utilization to go above the maximum compute capacity and to select a higher frequency than the current one.

The performance margin is now applied earlier in the path to take into account some utilization clampings and we can’t get an utilization higher than the maximum compute capacity.

We must use a frequency above the current frequency to get a chance to select a higher OPP when the current one becomes fully used. Apply the same margin and returns a frequency 25% higher than the current one in order to switch to the next OPP before we fully use the cpu at the current one.”

最后的修改很小，只有一行代码。

新闻出处，“A Fix For The Severe Linux Performance Regression Spotted By Torvalds”: https://www.phoronix.com/news/Torvalds-Perf-Regression-Fix。

关键词: Linux

Linux 6.8 在 IBM Z “s390” 上的系统调用执行性能提高了大约 11%

For those interested in Linux on IBM Z / s390, there’s a small change yielding measurable benefits to the s390 system call entry performance with the forthcoming Linux 6.8 kernel.

在即将推出的 Linux 6.8 内核中，有一个小小的改进，这对 s390 上的系统调用执行性能产生了肉眼可见的提高，这对于那些关注在 IBM Z/s390 上运行 Linux 的人来说是一个好消息。

此更改将各种 syscall 的入口 （entry）函数从 C 文件移动到内核各自的 common entry 头文件中，并设置为始终 inline 方式。由于针对 s390 架构也采用了 common entry，因此对系统调用的 enter/exit 函数始终 inline 可显著提高性能。

IBM Linux 团队的 Sven Schnelle 指出，通过始终 inline 那些 generic 的 syscall enter/exit 函数，通过一个小测试用例，他发现系统调用开销下降了大约 11%。这对于系统调用性能来说是一个非常不错的改进，而这只需针对 s390，移动大约 130 行代码。

截至上周，有关 syscall enter/exit 修改的三个补丁已合并进入 Linux 6.8 中。这些很小的改动却对 Linux 内核产生了很重要的性能优化效果，这真是一件值得高兴的事情。

新闻出处，“Linux On IBM Z “s390” To See ~11% Higher Syscall Entry Performance On Linux 6.8”: https://www.phoronix.com/news/Linux-6.8-s390-Syscall-Perf。

关键词: Linux, s390

用 Rust 编写 Linux 的调度程序

A Canonical engineer has been experimenting with implementing a Linux scheduler within the Rust programming language. His early results are interesting and hopeful around the potential of a Rust-based scheduler that works via sched_ext for implementing a scheduler using eBPF that can be loaded during run-time.

Andrea Righi 是 Ubuntu 制造商 Canonical 的 Linux 内核工程师, 他一直在尝试使用 Rust 编程语言实现 Linux 调度器。他的早期尝试很有趣，让我们对基于 Rust 开发调度器的潜力充满希望，该调度器通过 sched_ext 来实现一个使用 eBPF 的调度器，该调度器可以在运行时加载。Andrea 利用刚刚过去的圣诞假期开发了这个小玩意，他在推特上的原话如下：

“I ended up writing a Linux scheduler in Rust using sched-ext during Christmas break, just for fun. I’m pretty shocked to see that it doesn’t just work, but it can even outperform the default Linux scheduler (EEVDF) with certain workloads (i.e., gaming).”

他分享了一个 YouTube 视频 https://youtu.be/oCfVbz9jvVQ，展示了一款带有 “scx_rustland” 调度器的游戏，经对比测算，其性能优于默认的 Linux 内核调度器。如果你对这个工作感兴趣的话可以访问托管在 GitHub （https://github.com/sched-ext/scx/） 上的代码。

新闻出处，“Rust-Written Linux Scheduler Showing Promising Results For Gaming Performance”: https://www.phoronix.com/news/Rust-Linux-Scheduler-Experiment。

关键词: Linux, Rust, scheduler

GNU Hurd 的最新进展

While GNU Hurd predates the Linux kernel, its hardware support has been woefully behind with very limited and dated hardware support compared to modern PC/server hardware. Not only that, its been largely x86 limited but during Q4’2023 the developers involved have made progress on x86_64 support and begun tackling AArch64 porting.

虽然 GNU Hurd 的开发早于 Linux 内核，但它对现代硬件的支持一直非常缓慢且过时，甚至还主要局限在 x86 上。但在 2023 年第四季度，参与其中的开发人员在 x86_64 支持方面取得了进展，并开始处理 AArch64 移植问题。

开发者 Samuel Thibault 分享说，GNU Hurd 64 位移植现在在 debian-ports 仓库中已经有足够的软件包来引导 chroot。一个 64 位的 Debian + GNU Hurd 构建已经就绪，其他基础设施工作也在准备中。但 Samuel 指出构建软件包还不是很稳定。

在本周发布的 GNU Hurd 2023 年第四季度的新闻中指出，现在有很多人在致力于 Hurd 的 64 位支持。引导 chroot 已经可以工作，但为 64 位 Hurd 可靠地构建软件包仍然是一个持续存在的问题，并且在此过程中还发现了 proc leak 的问题。

该新闻还指出，该项目一直致力于建立持续集成 （CI） 测试，各种应用程序移植工作正在进行中，例如 Web 浏览器，并且还开始了对 AArch64 的移植。另一位开发人员也在致力于将 GNU Mach 移植到 POWER9 上。

可见进入 2024 年后，GNU Hurd 仍然在取得进展，但这仍然是一个缓慢的事情，我们只能说对 x86_64 的支持至少正在逐渐接近可用状态。

新闻出处，“GNU Hurd Has Been Making Progress On Its x86_64 Support”: https://www.phoronix.com/news/GNU-Hurd-x86_64-2023-Progress。

关键词: GNU Hurd

LLVM 18 计划于 3 月初发布

Tom Stellard announced plans this past week for releasing the LLVM 18 compiler stack in early March.

Tom Stellard 上周宣布了在 3 月初发布 LLVM 18 的计划。

根据 LLVM 开发人员制定的计划，LLVM 18.1 有望在 3 月 5 日发布。根据最新的 LLVM 版本编号命名规则，LLVM 将转向使用像 GCC 那样的版本命名方案，第一个稳定版本将被命名为 N.1。所以，3 月初的第一个稳定版本编号将是 LLVM 18.1，而按照以前的习惯，应该是叫 LLVM 18.0。

为了满足 3 月 5 日的发布日期，计划在下周的 1 月 23 日对 LLVM 18.x 的代码拉新的分支。第一个 RC 版本将于下周发布，下一个 RC 版本将在 2 月 6 日左右发布，第三个也是最后一个 RC 版本将在 2 月 20 日左右发布。

因此，根据发布时间表，如果一切顺利，LLVM 18.1 将在 3 月的第一周发布。LLVM 18 将引入更多新的功能，包括对 Intel APX 和 AVX10 扩展、Clang 中初始的 OpenACC 代码、对 OpenMP 内核语言的支持、对 Arrow Lake 和 Lunar Lake 等新 Intel CPU 的支持、初始 AMD GFX12 支持等方面。

新闻出处，“LLVM 18 Planned For Release In Early March”: https://www.phoronix.com/news/LLVM-18-Release-Schedule。

关键词: LLVM

联系我们

欢迎扫描二维码加微信联系我们：