GPUDirect Storage 概览指南-v1.19.1（二）

点击蓝字

关注我们

1.2.2.2 跨线程并发

注意

所有API都是线程安全的。

使用GDS是一种性能优化。在应用程序功能上能够通过将GPU缓冲区指针向下传递通过应用层来直接在存储与GPU缓冲区之间移动数据之后，性能是下一个关注点。系统级的IO性能来自多条链路和多个设备上的并发传输。每个4x4 NVMe PCIe设备需要并发传输才能从一条x16 PCIe链路获得全带宽。由于每个GPU和每个NIC都有PCIe链路，需要许多并发传输才能饱和系统。GDS不会提升并发性，因此这种级别的性能调优由应用程序管理。

1.2.2.3 异步性

CPU与一个或多个GPU之间的另一种并发形式可以通过应用程序线程中的异步性来实现。

在此过程中，工作由CPU提交以延迟执行，CPU可以继续向GPU提交更多工作或在CPU上完成工作。此过程在CUDA中增加了对异步IO的支持，可以启用包含IO的相互依赖工作图以延迟执行方式提交。

1.2.2.4 批处理

从应用程序向cuFile实现提交每次都有固定开销。对于同时提交许多IO事务的使用模型，批处理通过在批次中的事务之间摊销该固定开销来降低开销，从而提高性能。

批处理API本质上是异步的。有关更多信息，请参阅《cuFile API参考指南》。

1.2.2.5 在cuFile中使用CUDA流

提供了一种机制，按照CUDA流语义执行I/O的异步提交和异步执行。

数据大小、缓冲区和文件中的偏移量可以根据前一个CUDA内核或函数的执行在有效范围内动态变化。

1.2.3 兼容性与通用性

虽然GDS的目的是避免使用CPU系统内存中的中转缓冲，但回退到这种方法的能力使cuFile API即使在次优情况下也能普遍使用。对于不支持的配置，提供了兼容模式，将IO操作映射到回退路径。

对于满足以下一个或多个条件的系统，此路径通过CPU系统内存暂存：

- 通过用户版本的cufile.json文件进行显式配置控制。有关更多信息，请参阅《cuFile API参考指南》。

- nvidia-fs.ko内核驱动不可用，例如因为未安装在主机上，而运行使用cuFile的应用程序的容器就在该主机上。对于NVMe挂载（本地或使用NVIDIA DOCA SNAP），在CUDA 12.8及更高版本中，cuFile不需要nvidia-fs.ko内核驱动。

- 所选文件挂载上缺少相关的GDS启用文件系统，例如因为使用的多个系统挂载之一不支持GDS。

- 文件系统特定条件，例如无法应用O_DIRECT时。正在进行文件系统底层分析的供应商、中间件开发者和用户应查阅《GPUDirect Storage O_DIRECT要求指南》以获取更多信息。

有关更多信息，请参阅《cuFile API参考指南》中的cuFileHandleRegister。

在兼容模式下，基于GPU的应用程序在存储与GPU内存之间传输的性能通常至少与不使用GDS时当前基于CPU的API相同或更好。CPU路径的测试仅限于基于POSIX的API以及不包括GDS的合格平台和文件系统。

即使可以使用GDS进行传输，也并不总是可以实现直接传输。以下是cuFile API无缝处理的一些情况示例：

- 缓冲区未对齐，例如：

  - 文件偏移量不是cufile块大小对齐的。

  - GPU内存缓冲区地址不是cufile块大小对齐的。

  - IO请求大小不是cufile块大小的倍数。

- 请求的IO大小太小，文件系统无法支持RDMA。

- 传输大小超过GPU BAR1窗口的大小。

- GPU内存缓冲区与存储之间的最佳传输路径涉及中间暂存缓冲区，例如使用NVLink。

兼容模式和需要额外步骤的情况的无缝处理拓宽了GDS的通用性，使其更易于使用。

1.2.4 监控

本节提供有关可用于跟踪GDS中功能和性能问题的监控设施的信息。

GDS支持以下监控设施来跟踪功能和性能问题：

Ftrace

GDS函数的导出符号可以使用Ftrace进行跟踪，还可以在libcufile.so库中使用静态跟踪点，但nvidia-fs.ko尚不支持跟踪点。有关更多信息，请参阅《GPUDirect Storage故障排除指南》。

日志记录

错误条件和调试输出可以生成到日志文件中。此信息对于影响许多API但只需报告一次或影响没有返回值报告错误的API的情况很有用。cufile.json文件用于至少选择报告级别，如ERROR、WARN、INFO、DEBUG和TRACE。

性能分析

GDS可以配置为收集各种统计信息。

这些设施以及第三方工具支持的限制在《GPUDirect Storage故障排除指南》中有更详细的描述。

1.2.5 GDS中解决方案的范围

GDS增加了当前操作系统不支持的新功能API，包括直接传输到GPU缓冲区、异步性和批处理。这些API提供了性能提升，具有平台调优和拓扑调优的路径和暂存选择，增加了持久价值。

cuFile API下的实现克服了当前操作系统的限制。其中一些限制是暂时的，可能会在未来的操作系统版本中移除。虽然这些解决方案目前不可用且可能需要时间被采用，但今天就需要其他GDS启用的解决方案。以下是GDS中当前可用的解决方案：

- 分布式文件系统的第三方供应商解决方案。

- 通过开源、上游Linux的长期支持，未来GDS实现将无缝使用。

- 通过修改的存储驱动程序的本地文件系统支持。

整体cuFile架构涉及组件的组合，一些来自NVIDIA，一些来自第三方。以下是NVIDIA原创内容的列表：

- 用户级cuFile库libcufile.so，在闭源代码中实现以下内容：

  - cuFile驱动API：cuFileDriver{Open, Close}

  - cuFileDriver{GetProperties, Set*}

1.2.6 动态路由

GDS动态路由是一项功能，用于为网络文件系统（如DDN-EXAScaler、VAST-NFS和WekaFS）上的文件选择cuFileReads和cuFileWrites的最佳路径。对于GPU不与存储NIC共享同一根端口的硬件平台，对等事务（p2p）可能具有更高的延迟，并且与PCIe交换机下的p2p流量相比效率较低。

通过此功能，基于平台配置，cuFile库尝试高效地将I/O路由到GPU或从GPU路由，而不必付出跨根端口p2p流量的代价。例如，如果存储NIC与另一个允许的GPU（例如GPU1）共享公共PCIe根端口，而目标GPU（例如GPU0）跨越CPU根复合体，cuFile库可以在GPU1上使用中转缓冲区执行到GPU1的p2p事务，然后将数据拷贝到目标GPU0。GPU之间的NVLink可以进一步加速后续的设备到设备（GPU1->GPU0）I/O传输，使用NVLink而非PCIe。

对于每个挂载/卷，cuFile库预先计算具有与可用存储NIC最小PCI距离的最佳GPU，用于路由I/O。在读写期间，cuFile检查目标GPU是否共享公共PCIe交换机，且不需要流量跨越CPU根复合体。如果路径已经是最佳的，则动态路由不适用；否则cuFile库选择一个候选GPU作为中间中转缓冲区，并执行到目标GPU缓冲区的设备到设备拷贝。

注意

**可能存在多个候选GPU用于暂存中间缓冲区，并且可能并非与所有存储NIC等距，在这种情况下，cuFile依赖底层文件系统驱动程序基于nvidia-fs回调接口为候选GPU选择最佳存储NIC，以基于GPU缓冲区选择最佳NIC。**

1.2.6.1 动态路由的cuFile配置

`properties.rdma_dynamic_routing`启用/禁用分布式文件系统（Lustre、WekaFS、NFS）的动态路由功能。默认情况下，此功能关闭。

在I/O传输到GPU会导致跨根端口PCIe传输的平台上，如果存在与存储NIC共享根端口的GPU，启用此功能可能有助于提高整体带宽。如果启用此功能，请在mount_table的文件系统特定部分或properties部分的rdma_dev_addr_list属性中提供挂载使用的IP地址。

```json

"rdma_dynamic_routing": false

```

`properties.rdma_dynamic_routing_order`表示路由规则。如果适用，路由策略根据指定的顺序选择。默认路由顺序如下所示。如果第一个策略不适用，则回退到下一个，依此类推。

- 策略GPU_MEM_NVLINKS：使用GPU内存和NVLink在GPU之间传输数据

- 策略GPU_MEM：使用GPU内存和PCIe在GPU之间传输数据

- 策略SYS_MEM：使用系统内存和PCIe将数据传输到GPU

- 策略P2P：使用P2P PCIe在NIC和GPU之间传输

```json

"rdma_dynamic_routing_order": [ "GPU_MEM_NVLINKS", "GPU_MEM", "SYS_MEM", "P2P"]

```

下表总结了动态路由可以适用的用例，并描述了每个路由策略。

表1.1：动态路由策略

示例路由顺序可以是：

"rdma_dynamic_routing_order": [ "GPU_MEM_NVLINKs", "SYS_MEM"]

一个用例是如果存在一对GPU但没有NVLink，路由策略将回退到使用系统内存进行I/O传输。

另一个示例路由顺序可以是：

"rdma_dynamic_routing_order": [ "SYS_MEM"]

如果指定了这样的顺序，那么即使存在一对具有NVLink的GPU，路由策略也将使用系统内存进行I/O传输。

1.2.6.2 DFS挂载的cuFile配置

用户可以通过json属性`rdma_dev_addr_list`向库指定分布式文件系统挂载使用的存储NIC列表。此信息由库用于计算可用于路由IO的最佳GPU。设备地址列表可以按层次格式指定。

表1.2：动态路由策略

示例RDMA配置

```json

{

  "lustre": {

    // 读/写的IO阈值（参数应为4K对齐），等于或低于此值时

    // cuFile将使用posix读/写

    "posix_gds_min_kb": 0,

    "rdma_dev_addr_list" : [],

    "mount_table" : {

      "/lustre/ai200/client1" : {

        "rdma_dev_addr_list" : ["172.172.1.40"]

      },

      "/lustre/ai200/client2" : {

        "rdma_dev_addr_list" : ["172.172.2.40"]

      }

    }

  },

  "nfs" : {

    "rdma_dev_addr_list" : [1],

    "mount_table" : {

      "/mnt/nfs/ib0/data/0" : {

        "rdma_dev_addr_list" : ["192.168.0.12"]

      },

      "/mnt/nfs/ib1/data/0" : {

        "rdma_dev_addr_list" : ["192.168.1.12"]

      },

      "/mnt/nfs/ib2/data/0" : {

        "rdma_dev_addr_list" : ["192.168.2.12"]

      },

      "/mnt/nfs/ib3/data/0" : {

        "rdma_dev_addr_list" : ["192.168.3.12"]

      }

    }

  },

  "weka" : {

    // 启用/禁用RDMA写

    "rdma_write_support" : false

  }

}

```

限制：

库无法区分通过配置指定的使用相同网络共享文件系统共享的多个挂载点；并将所有此类IP地址视为唯一条目。因此建议在配置中仅对唯一共享提供配置。

< 长按识别二维码添加好友 >

加入上述群聊

长按并关注

带你走进万物存储、万物智能、

万物互联信息革命新时代

微信号：SSDFans