目录
- mm/virtio: 跳过宿主机已清零页面的冗余清零
- guest_memfd 的 Direct Map 移除支持
- mm/memcontrol: 将 stock 从 mem_cgroup 下沉到 page_counter
- slub: 将 refill 剩余对象溢出到 percpu sheaves
- mm/migrate: longterm pin 迁移时等待 folio 引用计数
1. mm/mglru: 改进回收循环与脏页处理
系列：[PATCH v5 00/14] mm/mglru: improve reclaim loop and dirty folio handling作者： Kairui Song（腾讯）版本： v5（14个patch）
背景
MGLRU（Multi-Generation LRU，多代 LRU）自合入主线以来在大部分场景表现优异，但其 reclaim 循环（回收循环）设计较为复杂，各模块之间高度耦合，积累了若干性能缺陷。具体而言，aging（老化）、scan number calculation（扫描数量计算）与 reclaim loop（回收循环）三者相互缠绕，且 dirty folio（脏页）的 flush 触发逻辑独立于主循环之外，导致在重写回负载下响应不及时。部分问题已在生产环境中被观察到，另一部分则在开发 LSF/MM/BPF 联合 topic 的压力测试中被暴露。
在现有实现中，get_nr_to_scan() 在每次循环迭代时都重新计算扫描数量，并与 aging 的触发判断混在一起：当 should_run_aging() 返回需要 aging 时，函数直接返回 -1 触发 aging 并结束本次扫描，这导致在默认优先级下即便可以 evict（驱逐）也会跳过 aging，形成次优决策。dirty folio 的 flusher 唤醒则在整个 try_to_shrink_lruvec() 循环结束后才统一检测 sc->nr.file_taken 与 sc->nr.unqueued_dirty 的比值，粒度粗且触发滞后。另有一个严重问题：隔离时对 swap 约束的过早检查错误地拒绝了 lazyfree folio，且在节流（throttling）路径上 MGLRU 完全忽略了 writeback 节流，可在 cgroupv1 场景下引发 OOM。
解决的问题
- 扫描数量计算与 aging 耦合：每次迭代重算导致逻辑不清，且在默认优先级下跳过必要 aging，浪费一次迭代仅用于提升 priority，破坏多 cgroup 间的 reclaim 平衡。
- dirty folio flush 触发滞后：flusher 唤醒在整个回收循环结束后才检查，对于重写回负载响应迟缓，file cache refault 居高不下。
- lazyfree folio 在 NOIO 场景下被错误拒绝：
isolate_folio() 中的 swap 约束检查过于宽泛，拒绝了不需要 IO 的 lazyfree folio。 - MGLRU 缺少 writeback throttling：与经典 LRU 不同，MGLRU 在脏页节流路径上有缺失，可导致 cgroupv1 下 OOM。
如何做
Patch 1-2 是纯代码整理：提取公共函数 lruvec_evictable_size()，统一计算 lruvec 中可驱逐 folio 数量的逻辑，并对变量名做语义化重命名。
Patch 3 将批量限制（batch split）从 scan_folios() 内部移到调用者处，在 try_to_shrink_lruvec() 和 run_eviction() 中明确执行 min(nr_to_scan, MAX_LRU_BATCH)。
Patch 4（核心重构） 彻底重构了 reclaim 循环。将扫描数量的计算提前到循环开始前执行一次：nr_to_scan = get_nr_to_scan(lruvec, sc, memcg, swappiness)，随后循环中每次消耗 delta 递减 nr_to_scan，自然退出。Aging 的触发从计算函数中剥离，在循环体内通过 should_run_aging() 独立判断。get_nr_to_scan() 本身也简化为：计算全量 evictable 大小 → 按比例保护（apply_proportional_protection）→ 右移 priority，并在高压力下保证最小批量 SWAP_CLUSTER_MAX。
Patch 5 让 scan_folios() 返回精确扫描数，isolate_folios() 通过输出参数分别报告隔离数和扫描数。
Patch 6 将每次循环的批量从 MAX_LRU_BATCH 缩减为 MIN_LRU_BATCH，在固定总扫描预算下减小每次加锁的粒度，降低锁竞争并避免超量回收。
Patch 8 删除 isolate_folio() 中的 swap 约束早期拒绝检查，改由 shrink_folio_list() 中的 may_enter_fs() 以更精细的粒度处理。
Patch 10（关键性能改进） 将 dirty flusher 的唤醒从 try_to_shrink_lruvec() 末尾移入 evict_folios() 内部，紧跟在 shrink_folio_list() 之后立即检查：若隔离出的 folio 全是未入队的脏页，则立刻调用 wakeup_flusher_threads(WB_REASON_VMSCAN)，对于 cgroupv1 还追加 reclaim_throttle(pgdat, VMSCAN_THROTTLE_WRITEBACK)。
Patch 11-14 完成清理：移除不再需要的 reclaiming 参数，删除 sc->file_taken 和 sc->unqueued_dirty 字段，最终提取 handle_reclaim_writeback() 辅助函数，使 MGLRU 和经典 LRU 共享相同的 writeback 统计与节流逻辑。
收益
作者在 48 核 96 线程 NUMA 双节点、128G 内存、NVME 存储机器上的测试数据：
MongoDB YCSB workloadb（10G cgroup，95% 读 5% 更新，无 swap）：
"The test is done on NVME and the performance gap would be even larger for slow devices, such as HDD or network storage. We observed over 100% gain for some workloads with slow IO."
同时修复了 MGLRU 启用时即使仍有可驱逐 file folio 也触发 OOM 的问题（生产环境确认），以及 cgroupv1 下 dirty throttle 路径缺失导致的 OOM。
2. mm/rmap: 支持任意 folio 映射
系列：[PATCH RFC 00/13] mm/rmap: support arbitrary folio mappings作者： David Hildenbrand（Arm）版本： RFC v1（13个patch）
背景
Linux 内核的 rmap（Reverse Mapping，反向映射）机制依赖于 mapcount 计数器来追踪 folio 的映射状态，用于判断部分映射（partial mapping）、共享检测、内存统计等。历史上，内核维护了两套实现路径，通过 CONFIG_PAGE_MAPCOUNT 编译选项控制：精确模式下每个页面维护独立的 page->_mapcount，以及通过 folio->_nr_pages_mapped 追踪实际映射的页面数量；非精确模式（CONFIG_NO_PAGE_MAPCOUNT）则以 folio 级别的平均 mapcount 替代。这种分叉增加了代码复杂度，也让 folio->_nr_pages_mapped 成为高频映射/解映射操作的热点。
作者在 LSF/MM/BPF 的 topic "Towards removing CONFIG_PAGE_MAPCOUNT" 中指出，这套机制阻碍了 rmap 支持更灵活的大 folio 映射模式——例如一个跨越多个 PMD 的 folio 用 PMD 方式映射时，现有的 _entire_mapcount 语义无法正确表达这种情况。
解决的问题
folio->_nr_pages_mapped 在每次 PTE 映射/解映射时都需要原子增减，是 rmap 路径上的性能瓶颈。CONFIG_PAGE_MAPCOUNT 造成的代码分叉，在 fs/proc/task_mmu.c、mm/rmap.c 等多个文件中散布了大量条件分支。- 现有 mapcount 语义无法支持"任意 folio 映射"——如跨 PMD 边界的大 folio 以 PMD 粒度映射。
/proc/meminfo、/proc/$PID/smaps、/proc/kpagecount 等接口在不同 config 下行为不一致。
如何做
该系列共 13 个 patch，以渐进重构为核心策略，最终移除 CONFIG_PAGE_MAPCOUNT 并统一为"total mapped pages"（总映射页数）计数模型：
**移除 folio->_nr_pages_mapped**（patch 1）：停止对该字段的更新并彻底移除。部分映射检测改为通过 folio_average_page_mapcount() 实现：若平均 mapcount < 1，则认为 folio 存在未映射页面。
proc 接口统一（patch 2-6）：逐一删除 IS_ENABLED(CONFIG_PAGE_MAPCOUNT) 条件分支，numa_maps 的 mapmax、/proc/kpagecount、PM_MMAP_EXCLUSIVE 标志等全部改用统一的平均 mapcount 判断。
移除 CONFIG_PAGE_MAPCOUNT Kconfig 选项（patch 7）：彻底删除该选项及相关条件编译代码。
_large_mapcount 语义重定义（patch 8-9）：统一表示 folio 级别的映射计数，语义变为"total mapped pages"——每次 PMD 级映射增加 PMD_SIZE/PAGE_SIZE，每次 PTE 映射增加 1。
hugetlb 统一（patch 11）：hugetlb folio 的映射改为直接操作 _large_mapcount，统一到新模型。
支持任意 folio 映射（patch 13）：新的计数器可以直接表达任意粒度的映射，从而在 rmap 层面天然支持跨 PMD 的大 folio 映射。
整个系列净删除代码 301 行（-626 +325）。
收益
- 移除了 rmap 热路径上的
_nr_pages_mapped 原子操作，理论上减少多核并发映射场景下的 cache line bouncing。 - 代码量净减少约 300 行，消除
CONFIG_PAGE_MAPCOUNT 分叉，降低维护复杂度。 - 为后续"任意 folio 映射"特性（如 PMD 级别的大 folio mapping、PUD 级别的 hugetlb folio mapping）铺平了数据结构基础。
- 作者在封面信中坦言"尚未做性能调优"，该系列的重点是正确性与可扩展性。
3. 实现新的通用 pagewalk API
系列：[RFC PATCH 0/7] Implement a new generic pagewalk API作者： Oscar Salvador版本： RFC v1（7个patch）
背景
现有的页表遍历 API（mm/pagewalk.c，基于回调的 walk_page_range() 系列）在处理 HugeTLB 页面时存在长期设计缺陷：hugetlb 条目被统一模拟为普通 PTE 条目对待，而不是按实际的页表层级（PMD 或 PUD）解释。这导致调用方需要大量特殊处理逻辑（.hugetlb_entry 回调、重复代码），fs/proc/task_mmu.c 中 smaps、numa_maps、pagemap 的实现尤为复杂。
2025 年 LSF/MM/BPF 大会上，社区达成共识需要一个新 API，能够以统一方式遍历普通页和 hugetlb 页，内置锁管理和批处理（batching），让调用方无需感知 hugetlb 的特殊性。
解决的问题
- 现有 API 将 PMD/PUD 级的 hugetlb 条目伪装成 PTE，调用方必须自行处理页表层级不匹配问题。
- 页表锁（PTL）的获取和释放由调用方负责，容易出错。
fs/proc/task_mmu.c 中三个 proc 接口有大量相似但微妙不同的遍历逻辑，维护困难。- 不支持 contiguous PMD（arm64 CONT_PMD）映射的批处理遍历。
如何做
softleaf_from_pud() 基础设施（patch 1）：为 arm64、x86、s390 等架构添加 PUD 级别的 softleaf 操作支持，包括 uffd-wp 宏和 swap entry 转换函数。
pmd_huge_lock() / pud_huge_lock() 辅助函数（patch 2）：统一 HugeTLB 和 THP 共用的 PMD/PUD 锁操作逻辑。
**folio_pmd_batch()**（patch 3）：类比 folio_pte_batch()，实现 PMD 级别的批处理函数，专门用于 arm64 contiguous PMD 映射的 hugetlb 页面。
pt_range_walk 核心 API（patch 4）：新增类型系统（PT_TYPE_FOLIO、PT_TYPE_SWAP 等八种类型），状态结构体 pt_range_walk 封装遍历位置、结果信息、条目属性和锁状态。提供三段式接口：pt_range_walk_start() → pt_range_walk_next() → pt_range_walk_done()，内部通过 folio_pte_batch()/folio_pmd_batch() 实现批处理。
调用方迁移（patch 5-7）：将 smaps、numa_maps、pagemap 迁移到新 API，fs/proc/task_mmu.c 净减少约 530 行代码。
收益
- 三个 proc 接口迁移后净减少 500+ 行重复代码，可维护性大幅提升。
- HugeTLB 遍历路径不再需要特殊回调，与普通 THP 路径统一。
- 内置批处理在遍历大段连续映射时可显著减少页表遍历迭代次数。
- 为未来 hugetlb 支持 PUD/PMD 粒度 rmap 操作提供底层遍历基础。
- 作者坦承"仍有 bug，缺少 pte_hole 等功能"，当前主要目的是收集社区反馈。
4. 优化匿名大 folio 的解映射
系列：[PATCH v2 0/9] Optimize anonymous large folio unmapping作者： Dev Jain（ARM）版本： v2（9个patch）
背景
随着大 folio（large folio）在匿名内存路径上的推广，try_to_unmap_one() 成为 swap-out 关键路径上的热点函数。该函数通过 page_vma_mapped_walk 逐 PTE 遍历 folio 的所有映射，对于一个 64K large folio 映射于 4K 页表粒度的系统（如 arm64 contpte 场景），每次需要迭代 16 次。已有工作为 file large folio 实现了批量解映射，但匿名 large folio 由于需要同时处理 swap entry 分配、anon_rmap 引用计数、userfaultfd write-protect 标记等多个复杂步骤，留下了 uffd-wp VMA 不支持批量处理的限制。
解决的问题
try_to_unmap_one() 对 large folio 的逐 PTE 处理效率低下。- hugetlb、lazyfree、uffd-wp 三个特殊路径代码内联在主循环中，阻碍进一步批量优化。
- uffd-wp VMA 中
folio_unmap_pte_batch() 遇到 userfaultfd_wp(vma) 直接返回 1，强制每次只处理一个 PTE。 - swap 相关辅助函数和
folio_try_share_anon_rmap_pte() 缺乏批量版本。
如何做
Patch 1 修复 nr_pages 跨迭代状态残留的隐患。
Patch 2-4 提取 unmap_hugetlb_folio()、can_unmap_lazyfree_folio_range()、install_uffd_wp_ptes_if_needed() 三个辅助函数，将特殊路径从主循环中剥离。
Patch 5 删除 folio_unmap_pte_batch() 中的 uffd-wp 限制，使 uffd-wp VMA 也能走批量路径。
Patch 6-8 引入 folio_dup_swap_range()、folio_put_swap_range()、folio_try_share_anon_rmap_ptes() 三个批量版本函数。
Patch 9（最终启用） 在 try_to_unmap_one() 的匿名 folio 路径中将所有操作批量化：一次性清空 nr_pages 个 PTE，通过批量接口处理 rmap、swap entry、uffd-wp 和 rss 更新。
收益
Apple M3 虚拟机（arm64），256MB 64K large folio 的 MADV_PAGEOUT 测试：
arm64 收益主要来自减少 ptep_get() 调用和 contpte 展开时的 TLB flush 次数。
5. mm: 内存回收中脏页的批量 TLB 刷新
系列：[PATCH v3 0/5] mm: batch TLB flushing for dirty folios in vmscan作者： Zhang Peng（腾讯）版本： v3（5个patch）
背景
在内存回收路径 shrink_folio_list() 中，每个 dirty folio 需要 page out 前都会调用 try_to_unmap_flush_dirty() 进行 TLB flush，意味着一次 TLB shootdown（TLB 击落），即通过 IPI（Inter-Processor Interrupt）通知所有相关 CPU 无效化对应 TLB 条目。在多核系统上，频繁的 IPI 是显著的性能开销，大量 dirty folio 同时回收时会形成 IPI 风暴。
解决的问题
- 每个 dirty folio 独立触发 TLB shootdown，IPI 频率与 dirty folio 数量线性相关。
shrink_folio_list() 内部逻辑内联，难以提取批量处理点。
如何做
Patch 1-3 做重构铺垫：将 nr_reclaimed 纳入 reclaim_stat，提取 folio_active_bounce()、pageout_one()、folio_free()、folio_try_unmap() 辅助函数。
Patch 4 提取 folio_try_unmap() 封装 TTU flags 构建和 try_to_unmap() 调用。
Patch 5（核心实现） 引入 pageout_batch() 和 flush_folios（folio_batch 类型）。当遇到 dirty folio 且决定 page out 时，不再立即 flush + pageout，而是解锁 folio 后加入 flush_folios。当批次满（31个）或最终清理时，调用 pageout_batch()：对每个 folio 重新加锁检查状态，然后对整批 folio **统一调用一次 try_to_unmap_flush_dirty()**，最后逐个 pageout_one() 写出。
收益
stress-ng 压测（512M cgroup，16 worker，16 CPU，8G swap）：
6. mm/virtio: 跳过宿主机已清零页面的冗余清零
系列：[PATCH RFC 0/9] mm/virtio: skip redundant zeroing of host-zeroed reported pages作者： Michael S. Tsirkin（Red Hat）版本： RFC v1（9个patch）
背景
Virtio-balloon 的 free page reporting 允许虚拟机将空闲页信息上报给宿主机，宿主机通过 MADV_DONTNEED 回收后会将页面清零。当 guest 后续再分配这些页时，内核在 post_alloc_hook() 中仍会对 __GFP_ZERO 请求执行 kernel_init_pages()，或在缺页路径上调用 folio_zero_user()——这意味着每个页面被清零了两次，产生纯冗余开销，在 THP 场景下尤为显著。
解决的问题
- Guest 在缺页处理路径上对已被宿主机置零的页面执行冗余
memset，浪费 CPU 和 cache。 - THP 场景下每次 2MB 大页 mmap 需要对 512 个页面做无效清零。
- Hugetlb surplus pages 同样被重复清零。
如何做
PageReported 标志传播（patch 1）：修改 expand() 函数，在 buddy 分裂出的子页上保留 PageReported 标志。
魔数哨兵机制（patch 2）：新增 page_reporting_host_zeroes 静态键，在分配时将 page->private 设置为 MAGIC_PAGE_ZEROED（0x5A45524F，ASCII "ZERO"），post_alloc_hook() 检测到此魔数时跳过清零。
__GFP_PREZEROED 标志（patch 3）：新增 GFP 标志，指示 post_alloc_hook() 保留魔数哨兵，配套 folio_test_clear_prezeroed() 辅助函数供调用方检查。
各分配路径适配（patch 4-7）：alloc_anon_folio()、vma_alloc_anon_folio_pmd()、alloc_hugetlb_folio() 等路径添加预清零检查逻辑。
收益
2GB VM、1 vCPU，分配 256MB 匿名页：
| | | |
|---|
| | | task-clock -45%, cache-misses -76% |
| | | task-clock -97%, cache-misses -87% |
7. zram: 异步 GC 支持懒惰 slot 释放
系列：[RFC PATCH] zram: support asynchronous GC for lazy slot freeing作者： Barry Song（小米）版本： RFC v1（1个patch）
背景
在 Android 低内存场景下，进程被杀后内核需要释放 VMA 中所有映射的 swap 条目。对于 zram，slot_free() 涉及查找并释放压缩内存池条目，在大量 swap 条目场景下开销极大——占总释放开销的 80% 以上。问题核心在于释放匿名 folio 和释放 swap slot 两个操作本来独立，却在同步路径上串行执行。
解决的问题
zram_slot_free_notify() 同步执行 slot_free()，阻塞 anon folio 释放，拖慢内存归还速率。- 多进程同时被终止时，swap slot 的串行释放造成严重延迟叠加。
do_swap_page() swap-in 时同样需等待 slot_free() 完成。
如何做
在 zram 驱动层引入轻量级异步 GC 机制：
GC 位图与计数器：struct zram 新增 unsigned long *gc_map（per-slot bitmap）和 atomic64_t gc_slots（待 GC 计数）。
惰性标记：zram_slot_free_notify() 中通过 test_and_set_bit() 原子标记 gc_map，积累超过 200 个时通过 queue_work() 唤醒 GC worker。
背压保护：待 GC 超过 30000 个时退回同步 slot_free()，防止积压过多。
GC Worker：zram_gc_work() 遍历 gc_map，通过 slot_trylock() 非阻塞逐一释放。
生命周期安全：zram_meta_free() 先 flush_work() 等待 worker 完成再清理。
整个实现约 58 行代码完成。
收益
RK3588（ARM 大小核平台）实测：
8. guest_memfd 的 Direct Map 移除支持
系列：[PATCH v12 00/16] Direct Map Removal Support for guest_memfd作者： Patrick Roy、Nikita Kalyazin（Amazon）版本： v12（16个patch）
背景
Spectre 系列漏洞的根本原因在于 CPU 推测执行通过微架构侧信道泄露数据。一个有效的缓解手段是将 guest 内存从 host 内核的直接映射（direct map）中撤销——若内核页表中不存在指向 guest 内存的映射，推测执行时 MMU 会在产生可观测副效应前阻断访问。据 RAID'23 论文，约 60% 的推测执行安全问题属于此类别。guest_memfd（v6.7 引入的专用 KVM guest 内存接口）尚不支持此保护。
解决的问题
guest_memfd 中 guest 内存对内核线性地址仍可见，存在 Spectre 级泄露风险。set_direct_map_* API 以 struct page * 为参数，不适合 folio 场景。gup_fast_folio_allowed() 中的 direct map 检查与 secretmem 强耦合，无法泛化。- 缺少通用的
AS_NO_DIRECT_MAP 地址空间标志。
如何做
API 重构（patch 1-3）：将 set_direct_map_* 参数从 struct page * 改为 const void *addr，实现 folio_zap_direct_map() 和 folio_restore_direct_map() 辅助函数。
通用抽象（patch 5-6）：引入 AS_NO_DIRECT_MAP 地址空间标志，替换 gup_fast_folio_allowed() 中对 secretmem_mapping() 的特殊判断。
guest_memfd 集成（patch 7-10）：新增 GUEST_MEMFD_FLAG_NO_DIRECT_MAP flag，在 folio 分配/回收路径调用 folio_zap_direct_map() / folio_restore_direct_map()。提供架构级钩子 kvm_arch_gmem_supports_no_direct_map()（x86 和 arm64 均支持）。
selftests（patch 11-16）：完整的 KVM selftests 覆盖。
收益
- "约 60% 的推测执行安全问题可通过 direct map 移除来缓解"。
- 使
guest_memfd 虚拟机达到与 memfd_secret 相同级别的 Spectre 防护，无需依赖 SEV-SNP 或 TDX 等硬件加密。 - AWS Firecracker VMM 已发布对应分支，具有实际生产部署需求。
9. mm/memcontrol: 将 stock 从 mem_cgroup 下沉到 page_counter
系列：[PATCH 0/8 RFC] mm/memcontrol, page_counter: move stock from mem_cgroup to page_counter作者： Joshua Hahn版本： RFC v1（8个patch）
背景
memcg 的 per-CPU stock 机制缓存最近 charge 的 memcg 及预充值页数，形成快速路径。现有实现的限制：每 CPU 最多缓存 7 个 memcg（NR_MEMCG_STOCK），超出后随机驱逐产生不必要的层次遍历和抖动；stock 与 struct mem_cgroup 紧密耦合，无法为其他 page_counter（如 memsw）独立启用 stock；每个 stock slot 需持有 CSS 引用。
解决的问题
- 每 CPU 最多 7 个 memcg stock slot 的硬限制，超出后随机驱逐导致额外层次遍历。
- stock 与
mem_cgroup 耦合，阻碍未来扩展。 - drain 机制复杂（异步
work_struct、FLUSHING_CACHED_CHARGE 标志）。
如何做
核心设计：将 stock 下沉到 struct page_counter。新增 struct page_counter_stock __percpu *stock 和 unsigned int batch 字段。page_counter_stock 极简：仅含 local_trylock_t lock 和 unsigned long nr_pages。
Patch 1-3 实现 stock-aware 的 page_counter_try_charge()（先查 stock 快速路径，不够则贪婪 hierarchy charge）和 page_counter_uncharge()（先存 stock，超 batch 才 hierarchy cancel）。
Patch 4 实现 drain API：page_counter_drain_stock() 同步 drain 所有 CPU。
Patch 5 将 memcg 切换为使用新 stock：删除 consume_stock()/refill_stock()，drain_all_stock() 简化。
Patch 6-8 为 cgroupv1 memsw 启用独立 stock，清理旧代码。
收益
40 CPU 压测（charge/uncharge 路径）：单 cgroup 和中等 cgroup 数场景性能持平或略好。更重要的是消除了 7-memcg-per-CPU 硬限制和随机驱逐，使 stock 机制对新 page_counter 可复用（如 hugetlb、dmem）。
10. rust: 添加 Per-CPU 变量 API
系列：[PATCH v5 0/8] rust: Add Per-CPU Variable API作者： Mitchell Levy版本： v5（8个patch）
背景
Per-CPU 变量是 Linux 内核中减少锁竞争的核心机制。随着 Rust for Linux 项目推进，Rust 侧一直缺少安全的 per-CPU 变量 API。Rust 的所有权模型和借用检查器对并发访问有严格约束，而 per-CPU 变量"每 CPU 独享、CPU 内部单线程访问"的语义与 Rust 安全模型可以完美契合，但需要精心设计的类型系统来表达。
解决的问题
- 缺少等价于
DEFINE_PER_CPU 的 Rust 宏。
如何做
基础层（Patch 1-3）：Cpumask 添加 CpumaskIter 迭代器，封装 per-CPU 和 preempt C helpers。
核心抽象（Patch 4）：建立完整类型系统——PerCpuPtr<T>（per-CPU 指针，通过 gs 段寄存器计算地址）、CpuGuard（RAII 抢占控制，Drop 时自动 preempt_enable()）、PerCpuToken/CheckedPerCpuToken（安全访问令牌）、StaticPerCpuSymbol<T>（静态 per-CPU 声明）、define_per_cpu! 宏。
动态分配（Patch 5）：DynamicPerCpu<T> 封装 alloc_percpu，支持三种构造方式。
优化层（Patch 7-8）：为数值类型提供 PerCpuNumeric trait，通过内联汇编生成 add gs:[...] 指令，与 C 的 this_cpu_inc() 性能持平。
收益
- Rust 驱动可安全使用 per-CPU 无锁数据结构。
CpuGuard 的 RAII 设计将遗漏 preempt_enable 变为编译期错误。- 数值类型针孔优化使 Rust 端与 C 代码性能持平。
- 辅助符号不出现在最终
.ko 文件中，无额外二进制开销。
11. slub: 将 refill 剩余对象溢出到 percpu sheaves
系列：[RFC PATCH] slub: spill refill leftover objects into percpu sheaves作者： Hao Li版本： RFC v1（1个patch）
背景
SLUB 分配器的 sheave 机制中，__refill_objects_node() 从 partial slab 取出整个 freelist 后，若对象数超过请求所需，"剩余尾部"会通过 __slab_free() 慢路径归还。但既然调用方正在 bulk refill，说明有大量分配需求，将剩余对象保留在 per-CPU sheaf 中更合理。
解决的问题
- refill 路径中剩余对象通过
__slab_free 慢路径归还，引入不必要的锁操作。
如何做
在 __refill_objects_node() 中，获取 freelist 时同时计算剩余对象数。若满足条件（不超过 sheaf 容量、非 pfmemalloc、同 NUMA 节点、sheaf 有空位），则将剩余对象存入 per-CPU sheaf；否则回退到原有 __slab_free 路径。新增 SHEAF_SPILL 统计项。
收益
"在 will-it-scale 基准测试的 mmap2 场景下，性能提升约 **2~5%**。"
主要收益来自避免 __slab_free 慢路径锁操作，以及对象留在 per-CPU sheaf 中提高 L1 cache 命中率。
12. mm: 直接回收重试前要求 LRU 回收进展
系列：[PATCH] mm: Require LRU reclaim progress before retrying direct reclaim作者： Matt Fleming（Cloudflare）版本： v1（1个patch）
背景
直接回收的重试决策依赖 should_reclaim_retry()，它通过 zone_reclaimable_pages() 估算可回收页面量。但在仅配置 zram swap 的小内存系统中，匿名页换出到 zram 实质是内存内部搬移，回收效率极低。然而 zone_reclaimable_pages() 不感知这一点，导致分配器陷入"futile anon LRU churn"——CPU 时间浪费在毫无意义的匿名 LRU 扫描上。
解决的问题
- 匿名页 zram 无法有效回收时，分配器因"看到"大量可回收页而不断重试，陷入死循环。
- 回收进度信息对分配器不可见，无法区分 anon/file LRU 的实际回收量。
如何做
新增 struct reclaim_progress（含 nr_reclaimed、nr_anon、nr_file），try_to_free_pages() 通过出参传递分类统计。
在 should_reclaim_retry() 中引入进度门控：通过 reclaim_progress_sufficient() 检查上一轮某类 LRU 的回收量是否达到该类可回收量的阈值（默认 1%），只有达标才将该类 LRU 纳入 available 估算。
新增 /proc/sys/vm/reclaim_progress_pct sysctl（0-100，默认 1）。
收益
- 消除 zram 场景下的分配器空转，避免系统长时间卡顿。
- 减少无效 CPU 消耗，降低 LRU 锁竞争引起的整体卡顿。
13. mm/migrate: longterm pin 迁移时等待 folio 引用计数
系列：[RFC PATCH 0/2] mm/migrate: wait for folio refcount during longterm pin migration作者： John Hubbard（NVIDIA）版本： RFC v1（2个patch）
背景
FOLL_LONGTERM GUP 用于 RDMA、GPU 等长期 pin 场景。迁移 folio 的前提是引用计数符合预期值，但 GPU 等设备在执行内存操作期间会持有瞬时引用（如 cuMemset），现有代码最多 10 次忙等重试，几乎瞬间耗尽机会，对需要数毫秒才能完成的 GPU 操作远远不够。
解决的问题
- 10 次 busy-retry 在 GPU 场景中极易失败，影响 RDMA/GPGPU 可靠性。
folio_put() 在引用计数下降但未归零时不通知等待者。folio_put() 是极热路径（约 500 处调用），全局引入唤醒调用会严重影响性能。
如何做
Patch 1：在 folio_put()/folio_put_refs()/folios_put_refs() 中通过 static_branch_unlikely(&folio_put_wakeup_key) 条件唤醒。默认 key 为 false 时编译为 NOP，零开销。
Patch 2：migrate_pages() 入口处当 reason == MR_LONGTERM_PIN 时 static_branch_inc() 启用 key，退出时 static_branch_dec()。在重试点插入：
wait_var_event_timeout(&folio->_refcount,
folio_ref_count(folio) <= expected, HZ);
与 wake_up_var() 配对，GPU 一旦 folio_put() 即可唤醒等待者，最长超时 1 秒。
收益
- 显著提升 FOLL_LONGTERM 迁移成功率（只要瞬时引用在 1 秒内释放即可成功）。
- 零开销默认路径：非迁移场景
folio_put() 完全不受影响。
总结
新机制 / 新接口
| | |
|---|
| mm/rmap: support arbitrary folio mappings | 移除 CONFIG_PAGE_MAPCOUNT，统一为"total mapped pages"计数模型，支持跨 PMD 的任意 folio 映射 |
| Implement a new generic pagewalk API | LSF/MM/BPF 共识，新三段式 pt_range_walk API 统一 HugeTLB/THP 遍历，内置批处理 |
| Direct Map Removal for guest_memfd | AS_NO_DIRECT_MAP + folio_zap_direct_map()，缓解约 60% 的 Spectre 类攻击 |
| rust: Add Per-CPU Variable API | Rust 原生 per-CPU 变量声明与访问，RAII 抢占控制，数值类型针孔优化 |
| mm: Require LRU reclaim progress | 新 struct reclaim_progress + sysctl，按 anon/file 分类门控回收重试 |
| mm/migrate: wait for folio refcount | static key + wait_var_event_timeout 实现零开销条件唤醒，提升 longterm pin 迁移成功率 |
性能优化
| | |
|---|
| mm/mglru: improve reclaim loop | MongoDB +27.6% 吞吐、-21.9% 延迟、-43.3% file refault |
| Optimize anonymous large folio unmapping | arm64 swap-out -53%（37ms→17ms） |
| batch TLB flushing for dirty folios | TLB shootdown -68.2%、IPI -57.4%、吞吐 +26.9% |
| skip redundant zeroing of host-zeroed pages | Hugetlb task-clock -97%、常规 THP -45% |
| zram: async GC for lazy slot freeing | Unmap 提速 3.4x、swap-in 提速 1.22x |
| move stock from mem_cgroup to page_counter | 消除 7-memcg-per-CPU 硬限制，架构可扩展 |
| slub: spill refill leftover into sheaves | will-it-scale mmap2 +2~5% |
