PCIe BAR 深入解析：从设备地址窗口到 DMA 与 GPUDirect Storage

Fri, 21 Aug 2026 16:25:00 +0800

在操作系统驱动、高性能网卡、NVMe SSD 和 GPU 系统中，经常会同时看到 BAR、MMIO、DMA、IOMMU、peer-to-peer DMA、GPUDirect RDMA 和 GPUDirect Storage 等概念。这些名词都与“设备怎样通过 PCIe 交换控制信息和数据”有关，但它们处在不同层次。

最简洁的理解是：

BAR：让 CPU 能够定位并访问 PCIe 设备中的寄存器或显存窗口
DMA：让 PCIe 设备能够主动读取或写入系统内存
P2P DMA：让一个 PCIe 设备直接访问另一个 PCIe 设备暴露的地址空间
GDS：利用 DMA、GPU 内存映射和驱动协作，让存储数据尽量直接进入 GPU 显存

本文从 PCIe 地址空间和事务模型出发，解释 BAR 是如何分配和映射的，驱动为什么通过 BAR 下发命令，DMA 地址为什么不能简单等同于物理地址，以及 GPUDirect Storage 如何把这些机制组合成一条高性能数据路径。

一、先建立 PCIe 系统视图

一个典型服务器的 PCIe 拓扑如下：

                         CPU
                          │
                Memory Controller
                          │
                       Host RAM
                          │
                    Root Complex
                   ┌──────┴──────┐
                   │             │
              PCIe Switch    PCIe Endpoint
              ┌────┴────┐         GPU
              │         │
           NVMe SSD     NIC

CPU 和内存构成主机侧。Root Complex 把 CPU/内存系统连接到 PCIe fabric。NVMe、网卡和 GPU 通常是 Endpoint。PCIe Switch 用于扩展端口和转发事务。

uGDS 原理解析：在用户态打通 NVMe SSD 与 GPU 显存

Thu, 20 Aug 2026 13:55:00 +0800

大模型推理正在把存储重新推到系统性能的核心位置。模型权重、KV Cache、Embedding 和训练检查点都可能在 SSD、主存与 GPU 显存之间频繁搬运。传统路径通常要经过文件系统、内核块层、页缓存或用户态中转缓冲区，不但增加 CPU 开销，也让小块 I/O 延迟变得难以控制。

uGDS 是 ScaleX-IO 开源的一套用户态 GPU Direct Storage 开发库。它的核心思路很直接：

让 CPU 在用户态构造 NVMe 命令并管理提交队列与完成队列，由 SSD 通过 PCIe P2P DMA 直接读写 GPU 显存，从数据路径中绕开内核 NVMe 驱动和文件系统。

本文结合 uGDS 当前源码，解释它为什么快、一次 I/O 如何执行、内核模块与用户态库如何分工，以及使用这类“绕过内核”的存储栈时必须承担哪些工程责任。

一、uGDS 想解决什么问题

先看一条常见的数据读取路径：

NVMe SSD
   │
   ▼
内核 NVMe 驱动 → 块层 → 文件系统
   │
   ▼
主机内存缓冲区
   │
   ▼
GPU 显存

即使系统支持 Direct I/O，应用仍然通常要进入内核，由内核驱动准备 NVMe 命令、完成 DMA 映射并处理中断或轮询。若数据还要经过主机内存，再复制到 GPU，路径会更长。

PCIe on Hellokitty's Blog

PCIe BAR 深入解析：从设备地址窗口到 DMA 与 GPUDirect Storage

一、先建立 PCIe 系统视图

uGDS 原理解析：在用户态打通 NVMe SSD 与 GPU 显存

一、uGDS 想解决什么问题