4.2 文件系统钩子函数的重写示例

以 readpage 这一关键操作为例，展示迁移前后的变化：

// 迁移前（旧 API）— 每个 base page 单独操作
static int ext4_readpage(struct file *file, struct page *page)
{
    // page 可能是 compound page 的某个 page（不一定是 head）
    // 如果是 tail page，还需处理 compound_head
    return ext4_readahead_block(file->f_mapping, page->index, page);
}

// 迁移后（folio API）— 按逻辑页操作
static int ext4_read_folio(struct file *file, struct folio *folio)
{
    // folio 保证是 head，直接处理 16 pages（order-4，64KB）或 1 page
    size_t len = folio_size(folio);
    pgoff_t start = folio->index;
    
    // 文件系统可以直接操作整个 folio 区域
    return ext4_readahead_blocks(file->f_mapping, start, folio_order(folio));
}

4.3 仍在使用 page 的场景

并非所有场景都适合 folio。以下场景继续使用 struct page*：

• Slab 分配器：slab 返回的永远不会是 compound page，没有 head/tail 歧义
• 页表映射：PTE 永远是 base page 粒度
• DMA / IOMMU：IOMMU IOVA 映射以 base page 为单位
• 页帧号（PFN）操作：需要逐页处理物理页帧

内核通过 folio_page(folio, n) 提取 folio 中的第 n 个 page，供上述场景使用。

五、THP for Page Cache：Folio 解锁的新能力

5.1 问题场景

在 folio 出现之前，THP 只能用于匿名内存（MAP_ANONYMOUS mmap），三大限制导致其效果受限：

• 只能匿名映射：文件的 mmap 映射使用 base page
• 只能 madvise 触发：需显式标记 MADV_HUGEPAGE 才能尝试
• 碎片化导致分配失败：长期运行后，物理内存可能碎片化，无法找到连续 2MB

5.2 Folio 带来的文件支持 THP

Folio 完成了 THP in page cache 的基础设施，核心变化包括：

（1）filemap_alloc_folio()：按 hint 分配适当大小的 folio

struct folio *filemap_alloc_folio(gfp_t gfp, unsigned int order)
{
    struct folio *folio = folio_alloc(gfp, order);
    
    if (folio && >0) {
        // order >= HPAGE_PMD_ORDER (即 2MB) 的 folio 被视为"大页"
        folio_set_active(folio);  // 统计和回收使用
    }
    return folio;
}

（2）readahead 的自动升级

当 readahead 检测到顺序读模式时，会提示分配更大 order 的 folio：

// mm/readahead.c
void page_cache_ra_order(...)
{
    // ...
    if (_ra->ra_pages > 256) {
        // 顺序读扩大：分配 order-4 (64KB) 甚至 order-9 (2MB) 的 folio
        order = min(ra_order, 9);
        folio = filemap_alloc_folio(GFP | __GFP_NORETRY, order);
        filemap_add_folio(mapping, folio, index);
        // ...
    }
}

（3）writeback 按 folio 粒度写入

folio-aware 的 writeback 可以一次回写整个 2MB 区域（而非 512 个独立 4KB page），大幅减少文件系统块分配次数和 journal 事务提交次数。

5.3 实际性能影响

根据 kernel.org 邮件列表和社区 benchmark 数据：

六、生产环境实践与调优

6.1 查看系统的 folio/THP 状态

$ grep -i huge /proc/meminfo
AnonHugePages:   524288 kB    # 匿名 THP 使用量
ShmemHugePages:       0 kB    # 共享内存 THP（tmpfs 等）
FileHugePages:   1048576 kB    # 文件支持 THP 使用量（kernel 6.0+）
FilePMDMapped:    393216 kB    # 文件页表直接映射 2MB

$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

$ ls /sys/kernel/mm/hugepages/
hugepages-2048kB/    # 1024 x 2MB THP pool
hugepages-32768kB/   # ARM64 32MB (若支持)
hugepages-65536kB/   # 64KB (aarch64 级联页表)
hugepages-1048576kB/ # 1GB 巨型页（需静态预分配）

6.2 配置建议

OLTP 数据库（MySQL/PostgreSQL）：建议关闭匿名 THP（避免延迟尖刺），但内核文件 IO 层自动产生的 folio 通常有益——THP in page cache 是按需求逐文件产生的，不会产生 promote/defrag 的开销。

# 仅关闭匿名 THP，文件 THP 的行为由 readahead 逻辑自动管理
echo never > /sys/kernel/mm/transparent_hugepage/enabled
# 仍可使用 MADV_HUGEPAGE madvise 让特定 mmap 区域启用文件 THP

存储服务器（分布式存储/RADOS/Ceph）：开启大页预分配 + 文件 THP：

# 增加 THP pool
echo 4096 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
# readahead 自动升级为 2MB folio
echo always > /sys/kernel/mm/transparent_hugepage/enabled
# 预读窗口调大
echo 8192 > /sys/block/nvme0n1/queue/read_ahead_kb

虚拟化和容器：对 guest 来说，host 的 THP 仅影响 host 自身的 page cache。若使用 virtiofs 或 9p 传递文件，guest 内部的文件 IO 是否使用 THP 由 guest 内核决定。

6.3 关键内核启动参数

# 彻底禁用 THP（包括文件支持）
transparent_hugepage=never

# 仅通过 madvise 启用（推荐生产默认值）
transparent_hugepage=madvise

# 全局启用（适用于大多数场景）
transparent_hugepage=always

# 对 tmpfs/shmem 的全局 THP 设置
/sys/kernel/mm/transparent_hugepage/shmem_enabled
# 选项：always|within_size|advise|never|deny|force

七、安全视角：新的攻击面与缓解

7.1 TLB 侧信道与 folio

更大的 page 大小（2MB vs 4KB）意味着 TLB 条目覆盖的内存范围更大。这使得某些 TLB 侧信道攻击更容易（一个 TLB miss 可泄漏 2MB 的信息而非 4KB）。然而：

• 正向效应：更少的 TLB 条目意味着 KPTI（内核页表隔离）的 TLB 刷新开销更低
• 缓解：现代 CPU 的 TLB 按 page size 隔离，不同大小的 TLB 条目独立淘汰
• 实践：Spectre/Meltdown 缓解的 TLB 刷新开销与 page size 成反比

7.2 巨型页碎片化拒绝服务

申请 2MB 不可移动的 folio 可能加剧内存碎片化。Linux 内核通过以下机制缓解：

• defrag 水位：sysctl vm.extfrag_threshold 控制内存压缩触发阈值
• GFP 标志约束：GFP | __GFP_NORETRY 让 folio 分配失败时优雅降级为 smaller order
• 渐进式分配：先尝试 order-9（2MB），失败后回退到 order-6（256KB），再到 base page

八、代码实战：手动操作 folio

8.1 内核模块中的 folio 生命周期管理

#include <linux/fs.h>
#include <linux/pagemap.h>
#include <linux/falloc.h>

static int __init folio_demo_init(void)
{
    struct folio *folio;
    struct page *page0, *page1;
    void *addr;
    
    // 1. 分配一个 order-2 (16KB) 的 folio
    folio = folio_alloc(GFP_KERNEL, 2);
    if (!folio)
        return -ENOMEM;
    
    // 2. 锁定（防止被回收）
    folio_lock(folio);
    
    // 3. 映射到内核虚拟地址
    addr = folio_address(folio);
    memset(addr, 0, folio_size(folio));  // 使用 folio_size() 而非硬编码 PAGE_SIZE
    
    // 4. 操作 folio 中的子页
    page0 = folio_page(folio, 0);  // head page
    page1 = folio_page(folio, 1);  // 第2个 page
    SetPageDirty(page1);  // 标记子页 dirty（PG_dirty 只作用于 page 级）
    
    // 5. 引用计数操作
    folio_get(folio);  // +1
    // ... 使用 folio ...
    folio_put(folio);  // -1
    folio_put(folio);  // -1 → 触发释放
    
    pr_info("folio_demo: allocated 4 pages (order-2), addr %pK\n", addr);
    return 0;
}

static void __exit folio_demo_exit(void)
{
    pr_info("folio_demo: exited\n");
}

MODULE_LICENSE("GPL");

8.2 用户态观测 folio/THP 行为

# 通过 /proc/pid/smaps_rollup 查看进程级 THP 使用
$ grep -i anonhuge /proc/self/smaps_rollup
AnonHugePages:   131072 kB

# 通过 perf 追踪 THP 分配事件
$ perf stat -e dTLB-load-misses,iTLB-load-misses \
    -p $(pidof my_app) sleep 5

# 通过 ftrace 追踪 folio 分配
$ echo 1 > /sys/kernel/debug/tracing/events/kmem/mm_page_alloc_extfrag/enable
$ cat /sys/kernel/debug/tracing/trace_pipe
  # 查看哪些调用路径因碎片化导致分配降级

# 通过 /proc/vmstat 查看 THP 统计
$ grep thp /proc/vmstat
thp_fault_alloc             847    # THP 通过缺页分配的次数
thp_fault_fallback          23     # THP 降级为 base page 的次数
thp_file_alloc             1502    # 文件 THP 分配次数（folio）
thp_file_fallback           41     # 文件 THP 降级次数
thp_split_page               68    # THP 被拆分为 base page 的次数

九、未来演进路线

9.1 Folio 化的最终目标

Linux 内核社区的目标是将 page cache 的核心代码路径完全基于 folio，最终将 struct page 在虚拟内存层中逐步"降级"为仅由低级硬件接口（页表、DMA、slab）使用的类型。这不是短期内能完成的目标——数以万计的驱动和文件系统代码仍需逐步适配。

9.2 与 CXL.mem 的协同

CXL 2.0/3.0 引入的 CXL.mem（内存扩展）设备通常以 2MB 或 1GB 粒度映射。File-backed folio 天然适配大页面映射——主机可以将 CXL-attached 内存中的文件 THP（2MB folio）整体映射到用户态，避免多级页表遍历。这对 AI/ML 大模型训练中频繁加载参数文件的场景有直接性能价值。

9.3 Name-Based Mapping

更激进的方向是（Name-Based Mapping）——不将文件映射到虚拟地址空间的固定偏移，而是通过文件名 + offset 直接定位 page cache 条目。这可以消除 mmap 中 VM 管理的复杂度，从根本上避免 VMA 膨胀问题。Folio 已经为此铺平了道路——一个 order-N 的 folio 是一个自包含的逻辑单元，可以脱离虚拟地址空间单独管理。

十、总结

Memory Folios 绝非简单的重命名或类型包装，而是 Linux 内存管理架构的一次根本性简化。它解决了困扰内核开发者十余年的 compound page 歧义问题，为 THP 在 page cache 中的全面支持奠定基础，并通过类型安全提升代码可维护性。对于高性能存储、数据库、AI 训练和大规模虚拟化工作负载，理解 folio 的分配、锁定、引用和回收机制是优化 IO 吞吐和内存效率的关键。随着 Linux 6.x+ 的不断成熟，folio 已成为现代 Linux 存储栈的事实标准——掌握它，就是掌握了虚拟内存子系统的演进方向。