本期导读：以 OSSNA 上 Dirk 与 Linus 的 AI/内核对谈开场，随后是 LSFMM+BPF Summit 一连串 MM 议题——GCC 16 的 BPF 支持、私有内存节点、用 BPF 自定义 page cache 策略、改进 major page fault 处理、LLM patch review、分层内存控制器、自动化 THP 管理、以及移除 page mapcount 的最新进展。封面页本身即勾勒出"BPF 横扫一切 + MM 持续重构"的本期基调。

José Marchesi 给出 GCC-BPF 后端的年度更新，GCC 正逼近与 LLVM 工具链的功能对等。GNU 整条工具链 (binutils / DejaGNU / GNU poke / GDB) 现在都有 BPF 支持，但部分组件（如 GDB 的 BPF 模拟器）维护不足。本次重点是收尾让 GCC 通过内核 BPF self-tests 所需的最后几个修复，作者承诺整个会期保持 in-person 在场参与讨论。

越来越多设备（加速器、专用网卡、压缩 RAM 等）带着自己的特殊内存进入系统，但每个用例都在重复实现一部分 MM 子系统。讨论提出"私有内存节点"需要的三条属性：buddy 分配器不能 fallback 进去；只能被显式请求；内核服务不得意外触碰其中的 folio。当前内核中 buddy fallback 和热插拔设备内存的策略破坏了这些前提，需要新的抽象来统一管理。

Zussman 指出，无论传统 LRU 还是多代 LRU 都无法应对某些工作负载——例如一个金融数据库一边跑高优先级小查询、一边偶发低优先级大扫描，扫描会冲刷整个 page cache 导致下一次小查询雪崩 thrash。Vlastimil Babka 质疑了 access-twice 启发式为何失效。提案是用 BPF 让用户空间介入 page cache 的淘汰决策，允许工作负载自定义"哪些页面更不该被踢出"。

Per-VMA 锁本意是把缺页处理从 mmap_lock 卸压到 VMA 级别，但一旦缺页需要触发 I/O，内核仍会释放 per-VMA 锁、I/O 完成后再以 mmap_lock 重试，于是 mmap_lock 争用又回来了。Song 提出几条路径：用 VMA 锁而非 mmap_lock 重试（已有 patch series）；或干脆持着 VMA 锁等 I/O 完成。Lorenzo Stoakes、Shakeel Butt 等担心复杂度。本期评论最热的话题之一，反映社区对 MM 锁机制持续重构的关注。

由 Roman Gushchin、Chris Mason、Josef Bacik、Sasha Levin 主持的 plenary，讨论用 LLM 辅助 patch review 的现状，讨论之热以致下午又加了一个 filesystem 专场延续。Gushchin 用《魔戒》Bag End 配图调侃 "LLMs are coming to our pleasant code"，并展示 Linux 7.0 首次贡献者数量陡增约 50% 的统计——这正是他启动 Sashiko 项目的动因。Sashiko 定位在静态分析工具与人类 reviewer 之间，吸收双方优缺点。围绕 prompt 文件的维护、放置与协作方式展开热烈讨论。

CXL 等设备带来分层内存：本地 RAM 快但少，CXL 内存多但慢，而 memory controller 对此一无所知，导致同 cgroup 同负载下两个实例性能差异巨大。Hahn 提出在 memory controller 中增加分层感知的限额机制，让延迟敏感工作负载、托管服务的多租户公平性、以及性能可复现性得到保障——否则连"优化是否有效"都无法测量。

Pache 指出 THP 的 always 模式真的会因为进程触碰一个字节就分配 2MB 大页，造成浪费；他过去提的 defer 模式（完全交给 khugepaged 事后组装）也被认为不是正解。共识方向是新增 auto 模式：内存使用低于阈值时表现得像 always，超过阈值则表现得像 defer，并结合 khugepaged 与 "underutilized" shrinker 动态拆分。真正让 transparent huge pages 名副其实的下一步。

struct page 的 mapcount 字段维护成本越来越高，Hildenbrand 长期致力于移除它。6.15 起内核有了 NO_PAGE_MAPCOUNT 配置项启用替代代码路径，标记为 experimental——既因为代码本身实验性，也因为它会让部分会计数据精度下降，对用户空间影响未知。自该选项加入以来未收到问题报告。本次议题是希望推动它脱离实验阶段，作者表示这"可能是他最后一次在 LSFMM 上讨论此话题"。

OSSNA 2026 主题演讲中，Dirk Hohndel 与 Linus Torvalds 的第 30 次"无火炉边谈"。话题包括 3D 打印（两人共用同款打印机、都偏爱用编程方式描述模型的 OpenSCAD）、吉他效果器、7.1-rc4 内核发布，以及 Torvalds 与 AI 工具的"复杂关系"。Linus 强调自己只是 OpenSCAD 的用户而非贡献者，享受把建模当编程的过程——这种"工程师把一切问题文本化"的偏好也成为他看待 AI 的潜在底色。

Arnaud Le Hors 在 OSSNA 2026 介绍 OSI 的 Model Openness Tool (MOT)。许多自称"开源"的 LLM 实际只是"open weight"——权重可下载但远不满足 OSI 的 Open Source Definition。Le Hors 反问："你觉得 Hugging Face 上的模型都是开源的吗？"答案是否定的：许多厂商在自造许可证，重现了上世纪 90 年代开源萌芽期的混乱。MOT 用于评估一个模型的真实"开放度"，对抗当下 AI 领域普遍的 openwashing。

major page fault 路径中 per-VMA 锁与 mmap_lock 的取舍引发讨论——MM 锁的演进始终是高争议高复杂度的话题。

Sashiko 工具与 LLM 辅助 review 的讨论触动神经：LLM 该不该进入内核 review 流程、prompt 文件的协作方式、与静态分析/人审的分工，都是开放问题。