网站头条 第6页

Linux 内核的可扩展调度器类“sched_ext”持续启用新功能，允许通过 BPF 程序实现自定义 CPU 调度策略。在下个月即将发布的 Linux 7.1 版本周期之前，sched_ext 的开发代码中已排队引入一项名为 ‌SCX_ENQ_IMMED‌ 的新功能，用于更精确地控制任务何时被投放到 CPU 上执行。

‌SCX_ENQ_IMMED‌ 是 sched_ext 中的一个新标志（flag），用于控制任务入队行为：当一个任务可以立即开始运行时，该标志确保其被直接加入本地分发队列（Dispatch Queue, DSQ）。换句话说，如果任务具备立即执行的条件，它就会被优先处理。

长期从事 Linux 内核开发的 Tejun Heo 负责实现了这一 SCX_ENQ_IMMED 标志，并在补丁说明中解释道：

“为本地 DSQ 插入操作添加 SCX_ENQ_IMMED 入队标志。一旦任务以 IMMED 方式被调度，它要么立即获得 CPU 并持续运行，要么在无法执行时被重新送回 BPF 调度器。它绝不会滞留在本地 DSQ 中其他任务之后，也不会被更高优先级调度类抢占的 CPU 所阻塞。

……
该机制通过防止任务在本地 DSQ 中堆积，实现了对调度延迟更精细的控制。同时，它还支持子调度器之间进行机会性的 CPU 共享——如果没有此功能，某个子调度器可能会填满共享 CPU 的本地 DSQ，导致其他调度器难以获得使用机会。”

目前该补丁已合入 sched_ext 的 “for-7.1” Git 分支，预计将在下个月的 Linux 7.1 合并窗口期间正式提交。

转自 Linux 7.1 sched_ext To Add “SCX_ENQ_IMMED” For Tighter Control When Tasks Land On A CPU – Phoronix

快科技3月16日休息，随着AI对内存产能的不断侵占，游戏产业也开始重视内存供应危机，今年的GDC 2026上，许多开发者都提到内存问题，甚至认为可能改变未来游戏的开发方式。

据报道，在GDC会场上，内存短缺几乎成为开发者之间的热门话题，Polygon采访了许多与会者，如果没有主动提起内存的问题，那往往是对方先提到。

而内存短缺带来的最大影响之一，是开发者不再能假设玩家会持续升级电脑，因为随着硬件定价飙升，玩家可能就不会升级，直接影响了游戏的硬件需求设计。

报道指出，部分游戏团队已经开始对内存危机调整开发策略，如《乐高蝙蝠侠:黑暗骑士传奇》开发商近期就将的PC建议配置从原本的32GB内存下调至16GB。

因此游戏优化在GDC 2026会上成为热门议题，多场研讨会专门聚焦让游戏运行更有效率的方法，部分开发者认为未来游戏设计将不得不接受过时技术。

甚至不再追求极致画面并降低相关技术需求，无所不用其极减轻内存负担，并让游戏在较低规格的设备运行。

Lemonade 项目在实现 Linux 平台上的 Ryzen AI NPU 支持时，以 FastFlowLM 为基础，旨在“释放 Ryzen AI NPU 的潜能”。FastFlowLM 是一个专为 Ryzen AI 打造的、采用”NPU 优先（NPU-first）”架构的运行时环境。借助当前一代的 Ryzen AI NPU，FastFlowLM 可支持高达 256k token 的上下文长度。FastFlowLM 0.9.35 版本于今日上午发布，正式带来了原生的 Linux 支持。

有一份名为”Lemonade”的文档指南，详细阐述了如何在 Linux 系统上利用 FastFlowLM 和 Lemonade 工具链来运行大型语言模型（LLMs）。

在接下来的几天里，我将利用手头现有的硬件，尝试在 Linux 上启用 AMD Ryzen AI NPU（神经处理单元）的支持。遗憾的是，用于评测搭载 Ryzen AI Max+ 395 处理器的笔记本电脑——HP ZBook Ultra G1a 的样机，早已按规定归还；不过，实验室里还有 Framework Desktop 主机以及 Ryzen AI 300″Strix Point”架构的硬件可供使用。希望这次备受期待的 Ryzen AI NPU Linux LLM 支持测试能一切顺利，以便进行相关的基准性能测试。

此时的时机至关重要，因为 Ryzen AI Embedded P100 系列即将上市，Ryzen AI PRO 400 系列也将随之推出。鉴于这些系列的目标市场，它们在实际应用中采用 Linux 系统的比例肯定会高于典型的消费级 Windows 部署。如今，关于”Linux 平台上 Ryzen AI NPU 对 LLM 的支持”这一话题，终于有了实质性的内容可以讲述。

转自  AMD Ryzen AI NPUs Are Finally Useful Under Linux For Running LLMs – Phoronix

目前，Linux IPv6 网络栈既可以编译进 Linux 内核中，也可以编译为可加载内核模块，或者完全不编译。根据一位 SUSE 工程师提出的补丁方案，IPv6 网络栈将被限制为只能编译进内核，或者完全不编译（即移除作为可加载内核模块的选项）。取消将 IPv6 作为可加载内核模块的支持，将有助于简化部分代码，并降低 Linux 网络子系统的维护负担。

Linux 内核中的 IPv6 支持将继续保持为可选项，但将不再支持将其作为可加载模块进行编译。这一改动在很大程度上符合现实情况：大多数部署方案要么将 IPv6 直接内置于内核中，要么完全不启用；而将配置设为 CONFIG_IPV6=m（即编译为模块）的情况极为罕见。

Fernando Fernandez Mancera 在补丁的封面信（cover letter）中阐述了该补丁的意图，以及当前因必须支持模块化 IPv6 选项而带来的维护负担：

历史上，Linux 内核一直支持将 IPv6 协议栈编译为可加载模块。虽然在 IPv6 普及的早期阶段，这种做法合乎逻辑，但在现代的部署环境和发行版中，绝大多数情况要么将 IPv6 直接内置于内核中（CONFIG_IPV6=y），要么完全禁用它（CONFIG_IPV6=n）。尽管将 IPv6 模块化能为特定配置带来镜像体积缩小和内存节省的优势，但这种好处远远不及它给子系统在实现和维护方面所带来的架构负担。

为了使核心网络子系统、BPF（伯克利数据包过滤器）、Netfilter 以及各种设备驱动程序能够安全地与一个可能被卸载的 IPv6 模块进行交互，内核依赖于间接调用结构（如 ipv6_stub、ipv6_bpf_stub 和 nf_ipv6_ops），并针对 ICMPv6 发送器等组件采用了动态的 RCU（读拷贝更新）注册机制。

本补丁系列通过将 CONFIG_IPV6 从三态选项（tristate）改为布尔选项（boolean），从而解决了这一问题，强制规定 IPv6 要么被内置编译，要么被完全禁用。这使得我们能够彻底移除那些存根（stub）基础设施，并安全地将其替换为直接的函数调用。

鉴于将 IPv6 支持作为内核模块的做法并不普及，且该方案允许切换到更直接的函数调用（这将带来更高的安全性和潜在的性能提升），因此这一改动是合乎情理的。实现这些变更的补丁系列现已发布，正在 Linux 内核邮件列表上接受审查。

转自 L Linux Patches Make The IPv6 Stack Less Modular To Lower Architectural Burden – Phoronix

一段时间以来，Canonical 一直在开发 Authd，作为面向外部基于云的身份提供商的认证服务。Authd 从零开始设计，旨在为 Ubuntu 系统提供安全的身份与访问管理，但直到下个月即将发布的 Ubuntu 26.04 LTS 版本中，它才真正进入 Universe 软件源仓库。

Authd 目前尚未包含在 Ubuntu Linux 发布的存档中，但那些希望依赖它的系统管理员需要使用 Canonical 的 PPA 或从上游源进行构建。随着下个月的 Ubuntu 26.04 LTS 发布，这是它首次出现在官方 Ubuntu 存档——Universe 软件源仓库中。

Authd 允许 Ubuntu 系统使用 OpenID Connect 等现代标准，对用户进行云端身份提供商的认证。Authd 最初主要服务于 Microsoft Entra ID 和 Google Cloud IAM，尽管该守护进程在设计上是模块化的，也支持其他身份提供商。

Authd 的发展将遵循 Ubuntu 的发布节奏，随着 26.04 版本的发布，它将作为长期支持（LTS）生命周期的一部分得到支持。

希望了解更多关于 Authd 与 Ubuntu 26.04 LTS 相关信息的人，可以阅读今天的公告。Authd 的 Go 和 Rust 代码可以在 GitHub 上以开源形式找到。

转自  Ubuntu 26.04 LTS Officially Supporting Cloud-Based Authentication With Authd – Phoronix

SUSE 的 Richard Biener 发布了一份关于 GCC 16 开发状态的新报告。回归修复工作进展缓慢，但他们希望能在四月中旬发布一个候选版本。

Richard 在今天的 GCC 16 状态报告中分享：

“我们现在正处于 GCC 16 开发第四阶段的近两个月，在减少回归数量方面进展缓慢，特别是将 P1 类别的回归减少到零。

虽然目前只有 14 个 P1 类别的回归，但 GCC 16 将引入另外 14 个未分类（P3）的回归，以及 28 个类似的 P4 类别的回归，这些对于非发布关键语言或目标而言——你可能需要优先处理这些，以确保 GCC 16 对用户来说不会比 GCC 15 更差。”

历史上，我们预计 GCC 16 的 RC 将在四月中旬发布。”

他们目前正试图通过修复它们或将其降级为低优先级回归来消除 14 个 P1 回归，以在发布时间上实现零回归。截至撰写时，有 586 个 P2 回归和 190 个 P3 回归。

GCC 16 带来了许多变化，包括 Algol 68 编程语言前端、默认支持 C++20 标准、AMD Zen 6 “znver6” 的初始支持、支持使用 Picolibc 嵌入式 C 库、AVX10.2 和 APX 支持，为 Intel Nova Lake 准备就绪、各种性能优化、针对 Intel Wildcat Lake 的支持、更高的默认 LTO 分区数量以应对当今更高核心数的处理器、ARM64 上的函数多版本化不再是实验性的，以及这个主导的开源编译器栈中的许多其他变化。

转自  GCC 16 Compiler Aiming For Mid-April Release Candidate But “Slow” Progress On Fixes – Phoronix

随着主线 Linux 内核开始支持即将推出的 Nova Lake 集成显卡以及 Crescent Island AI 推理加速器中的 Xe3P 图形功能，Intel 的 Mesa OpenGL “Iris” 和 Vulkan “ANV” 驱动程序正在准备开始规划其 Xe3P 驱动程序支持。

随着正在进行的 Xe 内核模式驱动程序工作的推进，英特尔图形驱动程序工程师们正在准备在其 Mesa Vulkan 和 OpenGL 驱动程序中推出对 Xe3P 的支持。Mesa 中开始布局 Xe3P 的 GenXML 支持。英特尔在 Mesa 中的 GenXML 用于通过 Python 生成器从 XML 文件中获取硬件数据结构、命令和其他定义，以自动生成供其驱动程序使用的相关 C 代码。

随着 GenXML 的 Xe3P 准备工作，今天还合并了另一项更改，以使用 GFX_VERx10 “350”代码路径开始构建 ANV 和 Iris 驱动程序的 Xe3P。这不会让新硬件亮起，只是设置代码路径，以便之后填充内容以启用新的图形 IP。

对于那些想要跟踪 Xe3P 上游进展和当前状态的人来说，有一个上游跟踪工单。

看到 Mesa 的 Xe3P 工作开始进行，很棒，希望在新硬件 Xe3P 上市前能够顺利，如果没有任何延迟，预计 Nova Lake 将在年底左右上市。

转自  Intel Begins Preparations For Xe3P Upstreaming To Open-Source OpenGL & Vulkan Drivers – Phoronix

去年，AMD 和 Intel 作为 x86 生态系统顾问小组的一部分，宣布了用于 x86 内存标记的 ChkTag，以更好地对抗缓冲区溢出和使用后释放错误。在为 ChkTag 准备未来处理器时，Intel 已经开始调整他们的线性地址掩码（LAM）支持，以更好地与之配合。

ChkTag 将带来新的 x86 指令，用于检测内存安全违规，并提供各种其他控制，以在处理内存安全问题时提供很大的灵活性。线性地址掩码（LAM）是最近 Intel CPU 上已有的一个功能，允许元数据（如标签）存储在 64 位指针的上位，这些位通常被忽略或未使用。LAM 对垃圾收集器、内存清理程序、安全检查等非常有用。

Intel Linux 工程师们一直在准备一个稳定的 x86 LAM 用户界面，以应对 ChkTag。Intel 工程师 Maciej Wieczor-Retman 发布了最新的补丁，旨在简化考虑到 ChkTag 的 LAM 界面：

在 ChkTag 发布之后，值得准备一个稳定的 x86 线性地址掩码（lam）用户界面。lam 的一个重要方面是标签宽度，将其与其他行业解决方案对齐可以提供一个更流行、更通用的界面，其他技术可以加以利用。

ChkTag 将使用 4 位标签，而其他内存标记实现（例如 Arm 的 MTE）似乎也在朝着这个方向发展，因此将 Linux 中的 lam 聚合到相同的规范是合理的。尽管 x86 的 LAM 支持 6 位标签，但将 lam 默认设置为 4 位也是有益的，因为 ChkTag 可能是接口的主要用户，这样的连接应该会在未来简化事情。

如果将来出现用例，6 位标签可以作为调试功能提供，并且可以通过 debugfs 启用。

该补丁集还清理了一些引用 LAM_U48 的注释，该功能在内核中未实现，注释不应暗示可以启用。

这些最新的代码目前正在接受审查，以便合并到未来的 Linux 内核版本中。至于 ChkTag 本身，到目前为止，我们还没有看到任何编译器或内核补丁出现，但预计很快就会开始出现。

转自  Intel Adapting Linux’s LAM In Preparing For ChkTag – Phoronix

一系列内核补丁看起来将在今年春天提交给 Linux 7.1 内核周期，以优化调度器 HRTICK 计时器，从而允许其默认启用。

托马斯·格莱克纳和彼得·齐尔斯特拉一直在努力优化 HRTIMER 子系统的某些方面，以减少 HRTICK 计时器的开销，使其能够默认启用。高精度计时器“HRTICK”是调度器代码的一部分，用于利用高精度硬件计时器，而不是低频固定间隔系统计时器。选择 HRTICK 可以带来更好的系统响应性等好处。

Gleixner用最近的一组 48 个补丁解释了这一点：

“Peter 最近发布了一系列调整 hrtimer 子系统以减少调度器 hrtick 计时器开销的帖子，以便默认启用。

结果证明这是不完整的，并导致了对相关细节的更深入调查。

问题是，hrtick 截止时间在每次上下文切换时都会改变，并且也会被唤醒和平衡操作修改。在一个 hackbench 运行中，这会导致每秒大约 2500 个时钟事件重新编程周期，这在虚拟机中尤其有害，因为访问时钟事件设备意味着虚拟机退出。”

这些补丁的最终结果非常令人印象深刻：

“在所有上述修改完成后，启用 hrtick 不会比禁用 hrtick 模式导致回归。

时钟事件设备的重新编程频率从 ~2500/秒降低到 ~100/秒，对于一个具有约 25% 的虚假 hrtimer 中断率的 hackbench 运行。

有趣的是，使用以下命令行参数（’-l$LOOPS -p -s8’）的 hackbench 运行取得了惊人的改进：该参数使用大小为 8 字节的消息的管道。在一个 112 核的 SKL 机器上，这会导致：

NO HRTICK[_DL] HRTICK[_DL]
运行时间：0.840 秒 0.481 秒 ~-42%

其他消息大小高达 256，HRTICK 仍然能带来改进，但幅度不大。尚未调查其原因。”

相当大的改进。值得注意的是，这些补丁现在已排队在 tip/tip.git 的 sched/hrtick 分支中。随着补丁被 TIP 分支采纳，它们很可能在 4 月份的 Linux 7.1 合并窗口期间提交。

转自  Linux 7.1 Expected To See Nice Improvements For Reducing HRTICK Timer Overhead – Phoronix

今天发布了本周所有的 DRM/加速驱动修复，为即将在周日发布的 Linux 7.0-rc2 内核版本做准备。

本周 Direct Rendering Manager 子系统更新中，AMDXDNA 加速驱动针对 AMD Ryzen AI NPUs 的修复尤为突出。通常每周修复数量最多的是 AMDGPU 驱动或 Intel Xe，但这次 AMDXDNA 的修复数量超出了常规。

本周排队等待的 AMDXDNA 修复包括解决该驱动器的系统挂起失败问题、缓冲区溢出修复、输入清理修复、死锁修复、空指针解引用错误修复、越界访问修复以及固件加载修复。是的，许多这些现在被修复的 bug 都源于该驱动器使用 C 编程语言，而许多热情的个体肯定会争论这是另一个应该用 Rust 编写的内核驱动器案例，以利用其内存安全优势。

除了这些不同的 AMDXDNA 修复之外，还有一些 AMDGPU 修复用于用户队列 “UserQ” 支持、DC 显示修复、VCN 5 修复以及其他修复。至于 Intel Xe、Nouveau 和其他驱动器，只有一些小修复，没有什么特别突出的。

Linux 7.0-rc2 所提交的完整 DRM 修复列表可通过此拉取请求找到。

转自  Numerous AMDXDNA Ryzen AI Driver Fixes For Linux 7.0-rc2 – Phoronix