前三篇的迁移都在“普通内存 ↔ 普通内存”。但 GPU 显存 CPU 根本访问不到它是怎么被纳入进程地址空间、又怎么在缺页时自动迁回内存以及回迁时怎么选择numa node。这将是本文的主题。0. 本章要回答的问题GPU 显存这种 CPU 不能直接读的内存怎么变成进程页表里的一个页ZONE_DEVICE/ device private pageCPU 去访问一个“其实在显存里”的地址时会发生什么migrate_to_ram缺页回调device→host 迁移时那个“目标 CPU 页”是在哪分配、落在哪个 node 的第 3 问是重点。本文更多的是分析当前的实现是否考虑了NUMA至于怎么优化放在后文分析。1. HMM 与 ZONE_DEVICE把设备内存塞进内存地图1.1 为什么需要它统一内存SVM / HMM的目标是CPU 和 GPU 共享同一套虚拟地址一个指针两边都能用。难点在于——同一个虚拟地址其物理页可能此刻在系统内存、下一刻被迁到了显存。内核需要一种办法把“显存里的页”也表示成一个struct page挂进进程页表这样缺页、迁移、反向映射这些既有机制才能复用。ZONE_DEVICE就是这个办法它为设备内存创建struct page但标记成特殊类型。其中 GPU 显存用的是MEMORY_DEVICE_PRIVATEinclude/linux/memremap.h// include/linux/memremap.henummemory_type{/* 0 is reserved to catch uninitialized type fields */MEMORY_DEVICE_PRIVATE1,// 设备私有内存CPU 不能直接访问// ...};MEMORY_DEVICE_PRIVATE的含义这些页有struct page、能进页表但 CPU 不能直接解引用——CPU 一旦访问就触发缺页由驱动把它迁回真正的系统内存。1.2 显存怎么注册进来devm_memremap_pages驱动在初始化时把一段显存通过devm_memremap_pages()或memremap_pages()注册为ZONE_DEVICE内核为这段显存建立struct page数组并绑定一个struct dev_pagemapinclude/linux/memremap.h// include/linux/memremap.hstructdev_pagemap{// ...conststructdev_pagemap_ops*ops;// 关键设备页的行为回调// ...};structdev_pagemap_ops{void(*page_free)(structpage*page);vm_fault_t(*migrate_to_ram)(structvm_fault*vmf);// CPU 访问设备页时的缺页回调};GPU VRAM 一段物理区间devm_memremap_pages()注册为 ZONE_DEVICE生成 struct page 数组type MEMORY_DEVICE_PRIVATE绑定 dev_pagemap.ops.migrate_to_ram 驱动回调这些 page 可以挂进进程页表2. CPU 访问设备页migrate_to_ram缺页回调当一段 SVM 内存当前在显存页表项指向 device private page而 CPU 代码去读写它时MMU 发现这是特殊页触发缺页异常内核回到dev_pagemap_ops.migrate_to_ram这个回调——把页迁回系统内存再让 CPU 访问继续。KFD 路径的注册drivers/gpu/drm/amd/amdkfd/kfd_migrate.c// drivers/gpu/drm/amd/amdkfd/kfd_migrate.cstaticconststructdev_pagemap_opssvm_migrate_pgmap_ops{.page_freesvm_migrate_page_free,.migrate_to_ramsvm_migrate_to_ram,// CPU 缺页 → 迁回系统内存};svm_migrate_to_ram()最终调用svm_migrate_vram_to_ram()走的正是第 03 章的migrate_vma三段式方向标志选设备页kfd_migrate.c// kfd_migrate.c svm_migrate_vma_to_ram()if(adev-gmc.xgmi.connected_to_cpu)migrate.flagsMIGRATE_VMA_SELECT_DEVICE_COHERENT;elsemigrate.flagsMIGRATE_VMA_SELECT_DEVICE_PRIVATE;// 挑出设备私有页// ...rmigrate_vma_setup(migrate);// 收集源(显存)页// ... 驱动为每个源页分配一个“系统内存页”填进 migrate.dst[]migrate_vma_pages(migrate);migrate_vma_finalize(migrate);整条缺页迁回链路是否就在内存CPU 读写一个 SVM 地址页表项指向device private page?MMU 触发缺页dev_pagemap_ops.migrate_to_ram() svm_migrate_to_rammigrate_vma 三段式flags DEVICE_PRIVATE为每个显存页分配一个系统内存页 → dst[]拷贝、重映射、收尾CPU 访问继续这部分的详细原理可以从参考Linux 内存管理子系统的进化——从 MM 到 HMM。3. 目标 CPU 页在哪分配、落哪个 nodemigrate_vma三段式里“填dst[]”这一步在驱动手里填的时候用哪个 node 分配就决定了页迁回后落在哪个 node。3.1 AMD KFD 路径alloc_page_vma跟随 VMA 策略KFD 用svm_migrate_get_sys_page()分配目标系统页kfd_migrate.c// kfd_migrate.cstaticstructpage*svm_migrate_get_sys_page(structvm_area_struct*vma,unsignedlongaddr){structpage*page;pagealloc_page_vma(GFP_HIGHUSER,vma,addr);// ← 落点由 VMA 的 mempolicy 决定if(page)lock_page(page);returnpage;}alloc_page_vma()按这段 VMA 的 NUMA 内存策略分配没有特殊策略时就是 first-touch/当前 node。这里的“VMA 策略”就是第 02 章mbind设定的“地址段级策略”内核里挂在 VMA 上没设时退化成第 01 章讲的 first-touch。也就是说——KFD 迁回的落点取决于 VMA 策略或触发缺页的那个 CPU 所在 node而不是“GPU 物理上最近的 node”。3.2 DRMdrm_pagemap路径vma_alloc_folio/folio_allocIntel 的 DRM SVM 后端走drm_pagemap。它填目标页的函数是drm_pagemap_migrate_populate_ram_pfn()drivers/gpu/drm/drm_pagemap.c// drivers/gpu/drm/drm_pagemap.c drm_pagemap_migrate_populate_ram_pfn()/* TODO: Support fallback to single pages if THP allocation fails */if(vas)foliovma_alloc_folio(GFP_HIGHUSER,order,vas,addr);// 有 VMA跟随 VMA 策略elsefoliofolio_alloc(GFP_HIGHUSER,order);// 无 VMA直接落当前 node有vasVMA时vma_alloc_folio跟随 VMA 的 mempolicy等价于 first-touch落点是“碰它的 CPU”所在 node。无vas时如后台驱逐 evictfolio_alloc完全不带 node 偏好落在当前执行线程所在的 node。两种情况都没有把“发起迁移的 GPU 最近的那个 CPU node”作为参数。在 NPS4 / 多 socket 机器上这意味着页很可能迁到一个离目标 GPU 较远的 node后续 CPU 访问就吃了远程延迟——这正是发现的问题。3.3 两条路径对照路径分配目标页的函数落点依据是否考虑 GPU 邻近 nodeKFDalloc_page_vma(GFP_HIGHUSER, vma, addr)VMA mempolicy / 当前 node否DRMdrm_pagemap有 VMAvma_alloc_folio(...)VMA mempolicy否DRMdrm_pagemapevict无 VMAfolio_alloc(GFP_HIGHUSER, order)当前 node无偏好否结论现有 device→host 迁移的落点从来不是“GPU 最近的 node”而是“恰好碰它的 CPU”或“当前 node”。4. evict 路径除了 CPU 缺页触发的迁回还有一类是显存吃紧时的驱逐evict把 SVM 显存页赶回系统内存腾空间。evict 往往发生在没有用户 VMA 上下文的后台流程里正对应folio_allocvas NULL分支——连 VMA 策略都没有纯落当前 node离“最近 node”更远。所以 evict 路径是这个问题最明显的受害场景。触发迁回的两种来源有无CPU 缺页migrate_to_rampopulate_ram_pfn 分配目标页显存驱逐evict_to_ram有 VMA 上下文?vma_alloc_folio跟随 VMA 策略folio_alloc落当前 node落点都可能远离发起 GPU 的最近 node5. 本章小结把“目标 node”的旅程接到本章层现状应该怎样用户态/上层只说“迁回 SYSMEM”传入/推导出“GPU 最近的 node id”drm_pagemap 分配vma_alloc_folio/folio_alloc无 node 偏好用alloc_pages_node(nid, ...)之类带上目标 node落点碰它的 CPU / 当前 nodeGPU 邻近 node也就是说第 01 章“怎么反推 GPU 最近 node”、第 02 章“move_pages/分配 API 怎么指定 node”、第 03 章“node 参数怎么决定落点”到这里合流成一个具体的问题**在drm_pagemap的 populate_ram 分配处把正确的 node 传进去。总结下本文的技术要点ZONE_DEVICE/MEMORY_DEVICE_PRIVATE让显存拥有struct page、能进页表但 CPU 不能直接访问include/linux/memremap.h。驱动用devm_memremap_pages()注册显存绑定dev_pagemap.ops.migrate_to_ram回调。CPU 访问设备页触发缺页 →migrate_to_ram→migrate_vma三段式迁回系统内存。下面是本文的两个焦点问题焦点1目标 CPU 页由alloc_page_vmaKFD/vma_alloc_folio·folio_allocDRM分配落点是 VMA 策略或当前 node都不考虑 GPU 邻近 node。焦点2evict 路径无 VMA用folio_alloc纯落当前 node是问题最突出的场景。接下来讨论下可能的优化以及helios和GB200这种机架式系统中的numa。关联阅读01 你的内存不是一整块看懂 NUMA 与机器拓扑02 一段内存到底在哪个 node用户态 NUMA 编程接口03 页是怎么在 node 间搬家的内核 NUMA 与页迁移机制ZONE_DEVICE为设备内存创建 struct page