static struct slab *allocate_slab(struct kmem_cache *s, gfp_t flags, int node,
bool build_freelist, bool *allow_spinp)

while (allocated < slab->objects - 1) {
    p[allocated] = object;
    maybe_wipe_obj_freeptr(s, object);
    allocated++;
    object += s->size;
    object = setup_object(s, object);
}

Patch 在 include/trace/events/vmscan.h 中新增了两个 tracepoint，均置于 #ifdef CONFIG_LRU_GEN 保护下：

1. **mm_vmscan_lru_inc_min_seq**：记录 min_seq 递增事件，输出字段包括 memcg_id（内存控制组 ID）、type（LRU 类型，0 = anon，1 = file）、swappiness 和递增后的 min_seq 值。

2. **mm_vmscan_lru_inc_max_seq**：记录 max_seq 递增事件，输出字段包括 memcg_id、swappiness 和递增后的 max_seq 值（max_seq 对 anon 和 file 共享，不需要 type 字段）。

在 mm/vmscan.c 中，tracepoint 被插入到三个关键位置：inc_min_seq() 中 WRITE_ONCE() 之后、try_to_inc_min_seq() 中 WRITE_ONCE() 之后、inc_max_seq() 中 smp_store_release() 之后。

收益

作者提供了 tracepoint 的输出示例，展示了 kswapd0 在多个 memcg 上交替执行 min_seq 和 max_seq 递增的完整时序。这种精细的时序信息在 debugfs 快照中是无法获得的。开发者可以使用 trace-cmd、perf record -e mm_vmscan_lru_inc_min_seq 或 bpftrace 等工具实时分析 MGLRU 的代际演进行为，对诊断内存回收延迟、分析不同 memcg 间的回收公平性有直接价值。

5. mm/memory hotplug: O(1) zone 连续性检查优化

系列：[PATCH v2] mm/memory hotplug/unplug: Optimize zone contiguous check when changing pfn range作者： Yuan Liu版本： v2（1 个 patch）

背景

每个 zone 维护一个 contiguous 布尔标志，用于标识该 zone 内的所有 PFN 是否都有有效的 memmap 映射。当 zone->contiguous 为 true 时，pageblock_pfn_to_page() 函数可以直接调用 pfn_to_page() 而无需逐个检查 pfn_valid()，这是 compaction（内存规整）等热路径的关键优化。

当前实现中，set_zone_contiguous() 函数通过遍历 zone 内的每一个 pageblock 来验证连续性。在内存热插拔（memory hotplug）场景中，每次调用 move_pfn_range_to_zone() 或 remove_pfn_range_from_zone() 都会先 clear_zone_contiguous() 再重新扫描整个 zone。对于大内存系统（如 256GB 或 512GB 的虚拟机热插拔），这种全量扫描代价极其高昂。

解决的问题

• 热插拔大容量内存时，set_zone_contiguous() 的 O(zone_size) 全量扫描导致极长延迟（256GB 热插需要 10 秒，512GB 需要 36 秒）
• 每次 memory block 的 online/offline 都触发全 zone 扫描，造成不必要的重复计算

如何做

Patch 引入了增量式连续性追踪机制：

1. 新增 zone 成员 pages_with_online_memmap。 在 struct zone 中新增 unsigned long pages_with_online_memmap 字段，精确追踪 zone span 内拥有已初始化 memmap 的页面数量。

2. 重写 set_zone_contiguous() 为 O(1) 判断：

staticinlinevoidset_zone_contiguous(struct zone *zone)
{
if (zone->spanned_pages == zone->pages_with_online_memmap)
        zone->contiguous = true;
}

当 spanned_pages 等于 pages_with_online_memmap 时，说明 zone span 内没有空洞。

3. 增量维护计数器。 在 memmap_init_zone_range()（启动阶段）和 adjust_present_page_count()（热插拔路径）中同步更新计数器。计数器可能出现 undercount，但这是安全的——最坏情况只是回退到逐 pageblock 检查的旧路径。

收益

测试环境为 Intel Icelake 服务器，QEMU + virtio-mem：

6. mm/vmstat: 分散 vmstat_update 定时器消除惊群效应

系列：[PATCH] mm/vmstat: spread vmstat_update requeue across the stat interval作者： Breno Leitao版本： v1（1 个 patch）

背景

内核使用 per-CPU 的 vmstat_work（DEFERRABLE_WORK）定期将 per-CPU 的 vmstat 差异同步回全局计数器。当前代码使用 round_jiffies_relative(sysctl_stat_interval) 来计算下次触发时间。round_jiffies_relative() 会将所有 CPU 的定时器对齐到同一个秒边界，导致所有 CPU 同时触发 vmstat_update() → refresh_cpu_vm_stats() → decay_pcp_high() → free_pcppages_bulk()，所有调用都需要获取 zone->lock 自旋锁，形成典型的惊群效应（thundering herd）。

解决的问题

• 所有 CPU 的 vmstat_update 定时器因秒对齐同时触发，导致 zone->lock 严重争用
• 在多核系统（如 72-CPU）内存压力场景下，free_pcppages_bulk() 路径的锁竞争显著影响系统性能

如何做

引入新的 vmstat_spread_delay() 函数，将时间窗口均匀分配给所有在线 CPU：

staticunsignedlongvmstat_spread_delay(void)
{
unsignedlong interval = sysctl_stat_interval;
unsignedint nr_cpus = num_online_cpus();

if (nr_cpus <= 1)
return round_jiffies_relative(interval);

return interval + (interval * (smp_processor_id() % nr_cpus)) / nr_cpus;
}

每个 CPU 根据其 smp_processor_id() 获得唯一的偏移量，触发时间均匀分布在一个 interval 内。设计要点：不增加定时器中断次数；使用 DEFERRABLE_WORK 不会唤醒 idle CPU；单 CPU 场景退回原始行为。

收益

测试环境为 72-CPU aarch64 系统，使用 stress-ng --vm + perf lock contention：

开启 KASAN：

竞争次数下降 7.5 倍，总等待时间减少约 **60%**。

未开启 KASAN：

竞争次数减少约 **45%**，总等待时间减少约 **28%**。

7. mm/vmpressure: 高阶回收时跳过 socket 压力信号

系列：[PATCH] mm/vmpressure: skip socket pressure for costly order reclaim作者： JP Kobryn (Meta)版本： v1（1 个 patch）

背景

vmpressure 机制通过 scanned 与 reclaimed 的比值判断内存回收压力等级。当压力超过 VMPRESSURE_LOW 时，内核会触发 TCP 内存压力控制，导致网络栈减少 socket 缓冲区大小，降低 TCP 吞吐量。

问题在于：当 kswapd 因内存碎片化在高阶分配请求下进行回收时，会扫描大量页面但实际回收很少——因为页面正在被活跃使用，系统并不缺内存。这种"扫描多、回收少"被 vmpressure 误判为回收效率低下。作者指出："kswapd scans many pages but finds little to reclaim - the pages are actively in use and don't need to be freed."

解决的问题

• kswapd 在高阶回收（如 THP 透明大页场景）时产生误导性的 vmpressure 信号，导致 TCP 吞吐量被不必要地限制
• 系统空闲内存充足时，仅因碎片整理相关的高阶回收就触发 socket 压力，是 false positive

如何做

1. 接口变更：vmpressure() 新增 int order 参数。

2. 核心过滤逻辑： 原来的 if (level > VMPRESSURE_LOW) 被修改为：

if (level > VMPRESSURE_LOW && order <= PAGE_ALLOC_COSTLY_ORDER)

PAGE_ALLOC_COSTLY_ORDER 定义为 3，是内核中既有的分界线——超过此 order 的分配由 compaction 接管，不应触发 socket 压力。

3. 保持 memcg 和 priority 路径不受影响：vmpressure_prio() 传入 order 0，确保当回收优先级降到极低时 critical 信号不会被误拦截。

收益

作者未提供性能数据。从代码逻辑推断，此改动可避免运行网络密集型应用（如数据库、分布式存储）的服务器在 THP 高阶回收时 TCP 吞吐量被错误抑制。修改范围仅涉及 3 个文件共 24 行变动，与现有 PAGE_ALLOC_COSTLY_ORDER 语义一致。

8. mm: RWF_DONTCACHE 写性能改进

系列：[PATCH 0/4] mm: improve write performance with RWF_DONTCACHE作者： Jeff Layton版本： v1（4 个 patch）

背景

RWF_DONTCACHE（内核内部对应 IOCB_DONTCACHE 标志）是近期加入内核的一种 I/O 模式，介于传统 buffered I/O 和 direct I/O 之间：数据仍经过 page cache，但写入后会被标记为可优先驱逐（dropbehind），从而避免污染 page cache。nfsd 最近新增了 debugfs 控制，允许为读写分别选择 buffered、dontcache 或 direct 模式。

然而，作者在用 fio 做基准测试时发现，RWF_DONTCACHE 在写密集负载下表现极差。根本原因在于 generic_write_sync() 的实现：每次 IOCB_DONTCACHE 写入完成后都调用 filemap_flush_range() 并设置 nr_to_write=LONG_MAX，即刷新该范围内所有脏页。在并发写入场景下，这导致多个 writer 在 writeback 提交路径上严重串行化。

解决的问题

• 并发写入时 writeback 提交路径争用，吞吐量下降到 buffered I/O 的约 47%，出现多秒级尾延迟
• 单客户端顺序写入在文件大于 RAM 时（512GB 文件、256GB RAM），激进刷新触发 dirty throttling，吞吐量从 buffered 的 1442 MB/s 降至 575 MB/s
• PAGECACHE_TAG_WRITEBACK 清除时所有等待的 writer 同时发起 flush 造成惊群效应，reader p99.9 延迟飙升 83 倍

如何做

Patch 1：引入 filemap_dontcache_writeback_range()。 替代 filemap_flush_range()，实现两层限流：

• Skip-if-busy：通过 mapping_tagged(mapping, PAGECACHE_TAG_WRITEBACK) 检查是否已有 writeback 在进行，如果是则跳过本次 flush
• Proportional cap：将 nr_to_write 限制为本次写入的页数（nr_written / PAGE_SIZE），而非 LONG_MAX

intfilemap_dontcache_writeback_range(struct address_space *mapping,
loff_t start, loff_t end, ssize_t nr_written)
{
if (mapping_tagged(mapping, PAGECACHE_TAG_WRITEBACK))
return0;
    nr = (nr_written + PAGE_SIZE - 1) >> PAGE_SHIFT;
return filemap_writeback(mapping, start, end, WB_SYNC_NONE, &nr,
            WB_REASON_BACKGROUND);
}

Patch 2：增加原子 flush 守卫和 dirty pressure 逃逸阀。 新增 AS_DONTCACHE_FLUSHING 标志位，使用 test_and_set_bit() 确保同一时刻最多只有一个 dontcache writer 在执行 flush。还增加 dirty pressure 逃逸机制：当全局脏页数超过 dirty_ratio 阈值的 75% 时，绕过 skip-if-busy 强制 flush，防止触发 balance_dirty_pages() 限流。

收益

作者提供了 fio benchmark 数据。补丁前的 IOCB_DONTCACHE 写入吞吐量仅为 buffered I/O 的约 47%（单客户端 575 MB/s vs 1442 MB/s），并出现 multi-second tail latency。作者指出 skip-if-busy 单独使用时 "reader p99.9 spikes 83x"，比例限制单独使用时 "still serializes on xarray locks"，因此两种机制缺一不可。Patch 3-4 提供了可复现的 fio benchmark 套件。

9. mm/mempolicy: 修复 weighted_interleave_auto_store() 内存泄漏

系列：[PATCH v2] mm/mempolicy: fix memory leaks in weighted_interleave_auto_store()作者： Jackie Liu版本： v2（1 个 patch）

背景

Weighted interleave（加权交错）是内核 NUMA 内存策略的一种分配模式，v6.16 引入了自动调优（auto-tuning）功能（commit e341f9c3c841）。用户通过 sysfs 接口写入 true 或 false 来切换自动/手动模式，对应函数为 weighted_interleave_auto_store()。该函数在进入时分配一个新的 wi_state 结构体，然后根据用户输入执行不同逻辑路径，但存在两处内存泄漏。

解决的问题

• 泄漏 1（写 "false" 时）：当当前模式已经是 manual 时，函数直接 return count，但没有 kfree(new_wi_state)
• 泄漏 2（写 "true" 时）：代码跳过了 old_wi_state 的获取，rcu_assign_pointer() 覆盖了旧指针而清理路径因 old_wi_state == NULL 不执行。如作者所述："A user can trigger this repeatedly by writing '1' in a loop."

如何做

将 old_wi_state 的获取从条件分支内移到 mutex_lock 之后、条件判断之前，成为无条件执行的操作：

mutex_lock(&wi_state_lock);
old_wi_state = rcu_dereference_protected(wi_state,
            lockdep_is_held(&wi_state_lock));

if (old_wi_state && input == old_wi_state->mode_auto) {
    mutex_unlock(&wi_state_lock);
    kfree(new_wi_state);
return count;
}

统一 early return 路径确保 new_wi_state 被释放；确保旧状态被正确获取使清理路径能正常执行。

收益

纯正确性修复。消除两处内存泄漏，防止长时间运行的 NUMA 系统因反复切换 weighted interleave 模式导致内存缓慢增长。Patch 标记 Cc: stable@vger.kernel.org # v6.16+，将被回移到稳定分支。

10. LoongArch: mm: 修复非零 DRAM base 的 FLATMEM ARCH_PFN_OFFSET

系列：[PATCH v2] LoongArch: mm: fix FLATMEM ARCH_PFN_OFFSET for non-zero DRAM base作者： Ethan Yang版本： v2（1 个 patch）

背景

在 CONFIG_FLATMEM（平坦内存模型）下，内核通过 pfn_to_page() 将 PFN 转换为 struct page 指针，计算公式为 mem_map + (pfn - ARCH_PFN_OFFSET)。LoongArch 当前将 ARCH_PFN_OFFSET 定义为 PFN_UP(PHYS_OFFSET)，而 PHYS_OFFSET 默认为 0。如果系统的 DRAM 不从物理地址 0 开始，ARCH_PFN_OFFSET 就会小于实际 RAM base 的 PFN，导致 pfn_to_page() 计算出错误的指针。

解决的问题

• ARCH_PFN_OFFSET 小于实际 DRAM base PFN 时，pfn_to_page() 计算出的指针偏移了 mem_map 的预期起始位置
• 在 memmap_init_range() 初始化 struct page 数组时写入错误的内存区域，导致早期启动失败

如何做

修复分两部分，涉及 3 个文件共 5 行改动：

1. **arch/loongarch/include/asm/page.h**：将 ARCH_PFN_OFFSET 从编译期常量 PFN_UP(PHYS_OFFSET) 改为运行时变量 min_low_pfn
2. **arch/loongarch/kernel/mem.c**：在 memblock_init() 中设置 min_low_pfn = PFN_UP(memblock_start_of_DRAM())
3. **arch/loongarch/kernel/setup.c**：在处理 mem=xxx 命令行参数后重新计算 min_low_pfn

收益

关键的启动正确性修复。没有此修复，DRAM base 非零的 LoongArch FLATMEM 系统根本无法启动。仅影响 CONFIG_FLATMEM 配置，SPARSEMEM 不受影响。

总结

性能优化

新机制 / 新接口

Bug Fix

技术趋势

1. 批量化与高阶释放优化：Feature #1（SLUB 跳过 freelist）和 #2（连续页面高阶释放）都体现了内存分配/释放路径从"逐个处理"向"批量处理"演进的趋势，通过减少锁获取次数和链表操作来提升吞吐量。
2. 锁争用消除：Feature #6（vmstat 定时器错峰）和 #8（RWF_DONTCACHE writeback 去串行化）都瞄准了多 CPU 同时争抢同一把锁的惊群问题，采用时间维度的错峰策略而非更复杂的锁分拆。
3. Rust 驱动对 mm 子系统的反向驱动：Feature #3 的开发动机来自 Rust binder 驱动的实际需求，预示着 Rust 驱动的增多将推动 mm 核心 API 的完善。
4. MGLRU 可观测性增强：Feature #4 的 tracepoint 补齐了 MGLRU 调试工具链的缺口，反映了 MGLRU 从"新特性"向"生产级基础设施"成熟的过程。

需持续关注

• **mm: Free contiguous order-0 pages efficiently (v6)**：已修复显著的 vmalloc 性能回退，且带来额外优化，预计会被快速合入
• mm: improve write performance with RWF_DONTCACHE：RWF_DONTCACHE 是 nfsd 重要的性能模式，此系列的写性能修复对 NFS 服务端影响重大
• **mm/vmalloc: vrealloc() shrink (v9)**：已迭代 9 个版本，是 Rust binder 驱动的依赖项，合入在即
• **mm/slub: skip freelist construction (v2)**：54%-74% 的提升幅度引人注目，但需关注对 SLUB debug 和 KASAN 的兼容性审查