ZONE_DEVICE 介绍

ZONE_DEVICE 是什么，有什么用

📋 问题定位

• 所属子系统：内存管理（mm），核心文件 include/linux/mmzone.h、include/linux/memremap.h、mm/memremap.c、mm/migrate_device.c
• 核心概念：ZONE_DEVICE 是 zone 枚举中最特殊的一个 zone；memory_type（5 种设备内存类型）；dev_pagemap（设备内存元数据）；memremap_pages()（注册入口）

🎯 原理说明

1. 它是什么：一个”只挂名、不参与分配”的 zone

在内核的 zone 体系中，ZONE_DEVICE 排在最末位（include/linux/mmzone.h:957）：

enum zone_type {
    ZONE_DMA,
    ZONE_DMA32,
    ZONE_NORMAL,
    ZONE_MOVABLE,
#ifdef CONFIG_ZONE_DEVICE
    ZONE_DEVICE,
#endif
    __MAX_NR_ZONES
};

但它和其他 zone 有本质区别：ZONE_DEVICE 中的页面永远不进入 buddy 分配器、不出现在 LRU 链表中。用 Dan Williams 在 2017 LSFMM 的话说，它是”内存热插拔机制的上半部分”——它完成 struct page 的建立和映射，但不把页面”上线”给内核做普通分配。所以设备内存无法被 alloc_pages() 拿到，普通内存也无法被迁移进去（除了显式的设备迁移路径）。

它的存在意义只有一个：给非 CPU 侧内存（设备内存）分配 struct page，使它们能参与内核的统一内存管理基础设施（DMA 映射、迁移、页表映射、引用计数等）。

2. 五种设备内存类型（include/linux/memremap.h:68）

3. 注册流程：memremap_pages()（mm/memremap.c:266）

设备驱动通过 devm_memremap_pages() 把一段设备物理地址范围注册为 ZONE_DEVICE：

dev_pagemap 描述（type/ops/owner/ranges）
        │
        ▼
memremap_pages(pgmap, nid)
   ├─ 按 type 校验（PRIVATE 必须有 migrate_to_ram + folio_free + owner）
   ├─ 初始化 percpu_ref（引用计数，防止驱动卸载时页仍被使用）
   └─ pagemap_range() 逐个 range：
        ├─ 建立 vmemmap（struct page 数组，可用 altmap 放在设备内存自身）
        └─ 将 section 标记为 SECTION_TAINT_ZONE_DEVICE

struct dev_pagemap（include/linux/memremap.h:133）是这套机制的元数据结构：

struct dev_pagemap {
    struct vmem_altmap altmap;      /* vmemmap 元数据可下沉到设备内存 */
    struct percpu_ref ref;          /* 引用计数，防止 use-after-free */
    enum memory_type type;          /* 上表五种类型 */
    unsigned long vmemmap_shift;    /* 大 folio 化的 vmemmap（>0 表示 compound pages） */
    const struct dev_pagemap_ops *ops;
    void *owner;                    /* 驱动标识，防止跨驱动误访问 */
    ...
};

4. 核心工作流：以 GPU 私有内存为例（HMM/migrate_vma）

CPU 视角下，设备私有内存相当于”换出到显存的页”：

进程访问 GPU 页 → CPU page fault
        │
        ▼
do_handle_mm_fault → migrate_to_ram 回调（驱动实现）
        │  把设备页数据迁回系统 RAM
        ▼
migrate_vma_setup()  （mm/migrate_device.c:729）
   ├─ migrate_vma_collect()  收集 src/dst PFN 数组
   ├─ migrate_vma_unmap()    锁页 + 解除映射，检查是否被 pin
   ├─ 驱动分配目的内存并拷贝
   ├─ migrate_vma_pages()    迁移 struct page 状态
   └─ migrate_vma_finalize() 更新 CPU 页表指向新页

这正是 Popple 在 2025 LSFMM 提到的痛点：migrate_vma 以 PFN 数组为粒度工作，页面变大后（huge page）接口变得笨重，他希望支持迁移时的大页拆分/合并。

💡 适用场景（结合你提供的 LWN 素材）

与你 OLK 工作的强相关点：

• 你的 gmem（GPU 内存管理） 本质就是 MEMORY_DEVICE_PRIVATE 的驱动侧实现 + migrate_vma 流程定制
• 可靠内存/CXL 场景对应 MEMORY_DEVICE_COHERENT，注意其”禁止 pin、必须可逐出”的约束，这与 ZONE_MOVABLE 的 pin 限制文章（Tatashin 的 patch）是同一类设计哲学：可迁移性是内存灵活性的前提

💡 收益效果

• 消除地址空间分裂：程序员不再需要区分系统内存/设备内存，malloc 的数据可透明迁移（2025 年 GPU 带宽 ~1TB/s vs PCIe 32GB/s，数据就地访问收益巨大）
• 统一 struct page 抽象：DMA 映射、迁移、页表管理复用同一套机制，避免驱动各自为政（2017 年讨论中 pfn_t 方案因 SPARC64 cache aliasing 失败，最终回到”struct page 不可回避”的共识）
• 代价：struct page 开销（每 4KB 页 64 字节）；2017 年讨论的”大页 struct page”问题至今未解决（会增加热路径开销）；设备内存生命周期与驱动绑定，一旦驱动卸载而页仍被引用，需要 percpu_ref 兜底

💡 应用前景

• CXL 时代的关键基础设施：ZONE_DEVICE 是 CXL 内存进入内核的必经之路，MEMORY_DEVICE_COHERENT 直接支撑内存池化/分层内存
• 大页设备内存是下一站：Popple 的清理工作（6.15 引用计数修复）后，hugetlb/THP 级别的 device-private 页即将铺开（Balbir Singh 已发布 THP for device-private 系列）；dev_pagemap.vmemmap_shift 字段已为 folio 化 vmemmap 预留
• file-backed device-private 页：方向已明确（page cache 特例 + 只读共享），但按社区共识会”做对为止、不做复杂化”——OLK 若跟进，建议先做只读路径
• 维护视角：上游 6.6 分支已包含完整 ZONE_DEVICE/HMM 框架（CONFIG_ZONE_DEVICE/CONFIG_DEVICE_PRIVATE），OLK-6.6 的 gmem 补丁与上游 migrate_vma 的演进需持续同步，尤其注意 6.15 的 FS-DAX refcount 修复是否影响你们的 OOT 路径

  参考来源

• include/linux/mmzone.h:956-959 — ZONE_DEVICE 枚举定义
• include/linux/memremap.h:68-93 — memory_type 五种类型注释
• include/linux/memremap.h:133 — struct dev_pagemap 定义
• mm/memremap.c:266 — memremap_pages() 注册入口
• mm/migrate_device.c:729 — migrate_vma_setup() 迁移流程
• 用户提供素材：LWN 2025 LSFMM（Popple）、LWN 2017 LSFMM（Dan Williams/HMM）、LWN 2021（ZONE_MOVABLE pin 限制）

参考来源

• 来源: https://lwn.net/Articles/1016124/

• 来源: https://lwn.net/Articles/717555/

• 来源: https://lwn.net/Articles/717555/

• 来源: https://lwn.net/Articles/717601/

• 来源: https://lwn.net/Articles/717614/