}

团队最近在技术选型时对比了多个方案，这里分享一下我们的调研结果和最终决策依据。

style="display:

xmlns="http://www.w3.org/2000/svg">

d="M5,0

style="-webkit-tap-highlight-color:

rgba(0,

0)">

难度:

入门级
预计学习时间:

30-45分钟
前置知识:

---

Memory，共享虚拟内存）是一项允许CPU和GPU共享同一虚拟地址空间的技术。

在AMDGPU驱动中，SVM使得应用程序可以使用相同的指针在CPU和GPU上访问数据，而无需显式地进行内存拷贝。

这极大地简化了异构计算程序的开发，并提高了性能。

想象一下：你在CPU上创建了一个数组，然后直接把这个数组的指针传给GPU

kernel，GPU就能直接访问这个数据——这就是SVM的魔力。

后文我会经常用AMDGPU

SVM来表示该技术，在NVIDIA体系里叫做统一共享内存（Unified

Shared

id="CPU_17">传统CPU程序的内存模型

在传统的CPU程序中，程序员使用虚拟地址：

• 虚拟地址到物理地址的转换
• 页面的分配和回收
• 内存保护

id="_32">异构计算的挑战

当我们引入GPU计算时，传统模型面临挑战：

operator">*gpu_data

class="token

function">hipMalloc

class="token

operator">&gpu_data

class="token

function">hipMemcpy

class="token

punctuation">(gpu_data

class="token

punctuation">(gpu_data

class="token

function">hipMemcpy

class="token

punctuation">(cpu_data

class="token

punctuation">(gpu_data

class="token

punctuation">;

1. 双重内存管理：需要分别管理CPU内存和GPU内存
2. 显式数据拷贝：程序员必须手动调用memcpy
3. 指针不通用：CPU指针和GPU指针是不同的
4. 复杂度高：容易出错，代码难维护
5. 性能开销：频繁的数据拷贝浪费带宽

id="_57">统一内存的愿景

理想的模型应该是这样的：

单一地址空间：CPU和GPU使用相同的指针

✅

自动迁移：数据按需自动在CPU和GPU间迁移

✅

简化编程：程序员无需关心数据在哪里

✅

提高性能：避免不必要的拷贝

✅

支持复杂数据结构：链表、树等可以直接共享

---

1.2

id="_81">离散内存空间

传统GPU架构维护两个独立的内存空间：

代码解析：

• 这段代码实现了核心功能逻辑
• 注意异常处理和边界条件
• 生产环境建议添加日志记录

!important">+----------------+

+----------------+

1. 地址空间隔离：CPU和GPU各自维护页表
2. 数据复制：通过PCIe总线进行显式拷贝
3. 同步开销：需要fence等待拷贝完成
4. 内存浪费：数据可能同时存在于两处

id="_103">复杂数据结构的困境

对于复杂数据结构，传统模型几乎无法使用：

function">create_linked_list

class="token

无法直接传给GPU，需要先序列化、拷贝、再反序列化

id="_118">编程复杂度

开发者需要：

• 维护两套内存分配
• 追踪数据的位置
• 手动管理数据传输
• 处理同步问题

这使得GPU编程的学习曲线陡峭，开发效率低下。

---

1.3

id="_132">核心概念

SVM

CPU和GPU共享同一虚拟地址空间

代码解析：

• 这段代码实现了核心功能逻辑
• 注意异常处理和边界条件
• 生产环境建议添加日志记录

+----------------------------------+

0x0000

+----------------------------------+↓

↓CPU访问

id="1_Unified_Address_Space_154">1.

Address

function">cpu_function

class="token

punctuation">;

id="2_OnDemand_Page_Migration_162">2.

Page

Migration）

系统自动在系统内存和GPU显存间迁移页面：

页面故障处理（Page

Handling）

• GPU访问不存在的页面时触发GPU页面异常
• 驱动处理异常：迁移数据、建立页表映射
• GPU重新执行访问指令

id="4_Coherency_Management_172">4.

Management）

• CPU修改页面时，GPU的映射自动失效
• 通过MMU

  Notifier机制实现

• 确保CPU和GPU看到的数据一致

SVM的优势总结

方面	传统模型	SVM模型
地址空间	CPU/GPU分离	统一地址空间
数据传输	显式memcpy	自动按需迁移
指针使用	不同的指针	相同的指针
复杂数据结构	几乎不可用	完全支持
编程复杂度	高	低
内存效率	可能有冗余	更高效
性能	拷贝开销	避免不必要的拷贝

---

代码解析：

• 这段代码实现了核心功能逻辑
• 注意异常处理和边界条件
• 生产环境建议添加日志记录

┌─────────────────────────────────┐

统一虚拟地址空间

└─────────────────────────────────┘↓

CPU访问

┌─────────────────────────────────┐

物理内存

└─────────────────────────────────┘

id="1_HMM_Heterogeneous_Memory_Management_218">1.

HMM

Management)

Linux内核提供的异构内存管理框架：

• 统一管理CPU和设备内存
• 提供页面迁移接口
• 支持设备内存的虚拟化

MMU

Notifier

监听CPU页表变化：

function">mmu_notifier_invalidate_range

class="token

function">svm_range_cpu_invalidate_pagetables

class="token

id="3_GPUGPU_Page_Fault_236">3.

GPU页面异常（GPU

Fault）

当GPU访问未映射的页面时：

代码解析：

⚠️

踩坑记录：

我在实际项目中遇到过一个问题，这个配置在开发环境正常，但生产环境会报错。

后来发现是因为生产环境的版本不一致导致的。

建议大家在部署前一定要检查版本兼容性。

• 这段代码实现了核心功能逻辑
• 注意异常处理和边界条件
• 生产环境建议添加日志记录

!important">GPU访问地址0x12345000↓

页表中无映射

页面迁移引擎

使用SDMA（System

代码解析：

• 这段代码实现了核心功能逻辑
• 注意异常处理和边界条件
• 生产环境建议添加日志记录

id="_257">典型工作流程

让我们跟踪一个完整的SVM访问流程：

决定是否迁移到VRAM（取决于访问模式）

class="token

GPU继续访问data[1..1023]

class="token

CPU的MMU发现页面已迁移到VRAM

class="token

或者通过PCIe直接访问VRAM（如果支持）

---

1.5

function">load_image

class="token

string">"photo.jpg"

class="token

function">adjust_brightness

class="token

punctuation">(image

class="token

punctuation">(image

class="token

function">save_image

class="token

string">"result.jpg"

class="token

punctuation">(image

class="token

punctuation">;

优势：无需在处理阶段间拷贝图像数据。

function">allocate_matrix

class="token

function">initialize_matrix

class="token

punctuation">(matrix

class="token

punctuation">(matrix

class="token

function">converged

class="token

punctuation">(matrix

class="token

function">analyze_result

class="token

punctuation">(matrix

class="token

punctuation">;

优势：CPU和GPU可以协作处理，无需手动同步数据。

operator">*gradients

class="token

function">create_model

class="token

punctuation">(model

class="token

GPU反向传播backward_pass

class="token

punctuation">(model

class="token

function">adjust_learning_rate

class="token

punctuation">(model

class="token

punctuation">}

优势：复杂数据结构（链表、树）可以直接共享。

id="4_364">场景4：数据库查询加速

function">load_database

class="token

function">aggregate

class="token

punctuation">(results

class="token

punctuation">;

优势：避免将整个数据库拷贝到GPU显存。

id="_384">性能收益

根据AMD的测试数据，使用SVM可以：

• 减少30-50%的数据传输时间
• 降低内存占用（无需双份拷贝）
• 提高开发效率（代码量减少40%左右）

---

id="__393">

重点提示

1. SVM不等于自动优化：虽然SVM简化了编程，但仍需要合理设计数据访问模式以获得最佳性能。

2. 并非所有访问都会迁移：系统会根据访问模式智能决定是否迁移页面。

   频繁在CPU和GPU间切换的数据可能保持在系统内存。

3. 硬件支持要求：

   • GPU需要支持页面异常和重试（XNACK）
   • 需要IOMMU支持
   • AMD的GFX9及以后架构支持

4. 与传统模型共存：SVM是一个选项，传统的显式内存管理仍然可用，两者可以混合使用。

   id="__408">⚠️

   误区1：“SVM会自动让程序变快”

   • ✅

   正确理解：SVM简化编程并减少不必要的拷贝，但需要合理使用。

❌

误区2：“所有内存分配都自动是SVM”

• ✅

memory）或IOCTL来创建SVM范围。

❌

误区3：“SVM消除了所有数据传输”

• ✅

正确理解：数据迁移仍然发生，只是自动进行。

理解何时发生迁移很重要。

❌

误区4：“SVM对所有应用都有益”

• ✅

正确理解：对于数据访问模式简单、可预测的应用，传统模型可能更高效。

---

id="__424">

实践练习

1. 思考题：

   • 为什么链表、树等数据结构在传统GPU编程中难以使用？

   • SVM如何解决这个问题？

2. 对比练习：

   • 写一个简单的向量加法程序的伪代码
   • 分别用传统模型和SVM模型实现
   • 对比代码复杂度

3. 概念检查：

   • 什么是"统一地址空间"？

   • GPU页面异常是如何触发的？

   • MMU

     Notifier的作用是什么？

---

id="__442">

本章小结

• SVM的本质：让CPU和GPU共享同一虚拟地址空间
• 核心优势：简化编程、支持复杂数据结构、自动数据管理
• 关键机制：页面迁移、页面异常、MMU

  Notifier

• 适用场景：复杂数据结构、频繁CPU-GPU协作、大数据处理

通过SVM，异构计算从"可行"变成"易用"，这是GPU计算普及的重要技术基础。

---

下一步

在理解了SVM的概念后，下一章我们将深入探讨SVM所依赖的Linux内核基础知识，包括虚拟内存管理、MMU、页表等核心概念。

---

SVM相关的Linux内核基础

5. 返回