在現代數據中心加速 IO ： Magnum IO 存儲

這是世界上第四個帖子加速 IO系列它解決了存儲問題，并與我們的合作伙伴分享了最近的成果和方向。我們將介紹新的 GPU 直接存儲版本、優點和實施。

加速計算需要加速 IO 。否則，計算資源就會缺乏數據。考慮到所有工作流程中數據存儲在內存中的比例正在減少，優化存儲 IO 變得越來越重要。存儲數據的價值、竊取或破壞數據的行為以及保護數據的法規要求也在不斷增加。為此，人們對數據中心基礎設施的需求日益增長，這些基礎設施可以為用戶提供更大程度的隔離，使其與不應訪問的數據隔離開來。

GPU 直接存儲

GPU 直接存儲簡化了存儲和 GPU 緩沖區之間的數據流，適用于在 GPU 上消費或生成數據而無需 CPU 處理的應用程序。不需要增加延遲和阻礙帶寬的額外拷貝。這種簡單的優化導致了改變游戲規則的角色轉換，數據可以更快地從遠程存儲（而不是 CPU 內存）饋送到 GPU s 。

GPU 直系親屬的最新成員

GPUDirect系列技術能夠訪問 GPU 并有效地將數據移入和移出 GPU 。直到最近，它還專注于內存到內存的傳輸。隨著 GPU 直接存儲（GDS）的添加，使用存儲的訪問和數據移動也加快了。 GPU 直接存儲使在本地和遠程存儲之間向 CUDA 添加文件IO邁出了重要的一步。

使用 CUDA 11 . 4 發布 v1 . 0

GPU 直接存儲經過兩年多的審查，目前可作為生產軟件使用。 GDS 以前僅通過單獨安裝提供，現在已并入 CUDA 11 . 4 版及更高版本，它可以是 CUDA 安裝的一部分，也可以單獨安裝。對于 CUDA 版本X-Y的安裝，libcufile-X-Y. so 用戶庫gds-tools-X-Y默認安裝，nvidia-fs.ko內核驅動程序是可選安裝。有關更多信息，請參閱 GDS 故障排除和安裝文檔。

GDS 現在在RAPIDS中提供。它還有 PyTorch 集裝箱和MXNet 容器兩種版本。

GDS 說明和好處

GPU 直接存儲啟用存儲和 GPU 內存之間的直接數據路徑。在本地 NVMe 驅動器或與遠程存儲器通信的 NIC 中，使用直接內存訪問（ DMA ）引擎移動數據。

使用該 DMA 引擎意味著，盡管 DMA 的設置是一個 CPU 操作， CPU 和 GPU 完全不涉及數據路徑，使它們自由且不受阻礙（圖 1 ）。在左側，來自存儲器的數據通過 PCIe 交換機進入，通過 CPU 進入系統內存，然后一直返回 GPU 。在右側，數據路徑跳過 CPU 和系統內存。下面總結了這些好處。

無 GPU 直接存儲

受進出 CPU 的帶寬限制。導致 CPU 反彈緩沖區的延遲。內存容量限制為 0 （ 1TB ）。存儲不是 CUDA 的一部分。沒有基于拓撲的優化。

使用 GPU 直接存儲

GPU 的帶寬僅受 NIC 限制。由于直接復制，延遲更低。訪問 O （ PB ）容量。簡單的 CUDA 編程模型。通過 NVLink 、 GPU 緩沖區自適應路由。

圖 1 . GDS 軟件堆棧，其中應用程序使用 cuFile API ，啟用 GDS 的存儲驅動程序調用nvidia-fs.ko內核驅動程序以獲得正確的 DMA 地址。

GPU 直接存儲提供了三個基本的性能優勢：

• 增加帶寬：通過消除通過 CPU 中的反彈緩沖區的需要，在某些平臺上可以使用備用路徑，包括通過 PCIe 交換機或 NVLink 提供更高帶寬的平臺。雖然 DGX 平臺同時具有 PCIe 交換機和 NVLink ，但并非所有平臺都具有。我們建議使用這兩種方法來最大限度地提高性能。火星著陸器的例子實現了 8 倍的帶寬增益。
• 潛伏期縮短：通過 CPU 內存避免額外拷貝的延遲和管理內存的開銷（在極端情況下可能非常嚴重），從而減少延遲。延遲減少 3 倍是常見的。
• CPU 利用率降低：使用跳出緩沖區會在 CPU 上引入額外的操作，以執行額外的復制和管理內存緩沖區。當 CPU 利用率成為瓶頸時，有效帶寬會顯著下降。我們測量了多個文件系統的 CPU 利用率提高了 3 倍。

沒有 GDS ，只有一條可用的數據路徑：從存儲器到 CPU ，從 CPU 到具有 CUDA Memcpy 的相關 GPU 。對于 GDS ，還有其他可用的優化：

• 用于與 DMA 引擎交互的 CPU 線程與最近的 CPU 內核密切相關。
• 如果存儲器和 GPU 掛斷不同的插槽，并且 NVLink 是可用的連接，則數據可通過存儲器附近的 GPU 內存中的快速反彈緩沖區暫存，然后使用 CUDA 傳輸到最終的 GPU 內存目標緩沖區。這可能比使用 intersocket 路徑（例如 UPI ）快得多。
• 沒有cudaMemcpy參與分割 IO 傳輸，以適應 GPU BAR1 孔徑，其大小隨 GPU SKU 變化，或者在目標緩沖區未固定cuFileBufRegister的情況下，分割到預固定緩沖區。這些操作由libcufile.so用戶庫代碼管理。
• 處理未對齊的訪問，其中要傳輸的文件中的數據偏移量與頁面邊界不對齊。
• 在未來的GDS版本中，cuFileAPI將支持異步和批處理操作。這使得 CUDA 內核能夠在 CUDA 流中的讀取之后對其進行排序，該 CUDA 流為該內核提供輸入，并且在生成要寫入的數據的內核之后對寫入進行排序。隨著時間的推移，cuFileAPI也將在 CUDA 圖形的上下文中可用。

表 1 顯示了 NVIDIA DGX-2 和 DGX A100 系統的峰值和測量帶寬。該數據表明，在理想條件下，從本地存儲到 GPU s 的可實現帶寬超過了 CPU 內存的最大帶寬，最高可達 1 TB 。通常從 PB 級遠程內存測量的帶寬可能是 CPU 內存實際提供帶寬的兩倍以上。

將 GPU 內存中無法容納的數據溢出到甚至 PB 的遠程存儲中，可能會超過將其分頁回 CPU 內存中 1 TB 的可實現性能。這是歷史的一次顯著逆轉。

*此處顯示的 NVIDIA GPU 直接存儲在 NVIDIA DGX A100 插槽 0-3 和 6-9 上的性能數字不是官方支持的網絡配置，僅供實驗使用。為計算和存儲共享相同的網絡適配器可能會影響 NVIDIA 先前在 DGX A100 系統上發布的標準或其他基準測試的性能。

GDS 的工作原理

NVIDIA 尋求盡可能采用現有標準，并在必要時明智地擴展這些標準。 POSIX 標準的pread和pwrite提供了存儲和 CPU 緩沖區之間的拷貝，但尚未啟用到 GPU 緩沖區的拷貝。隨著時間的推移， Linux 內核中不支持 GPU 緩沖區的缺點將得到解決。

一種稱為 dma _ buf 的解決方案正在進行中，該解決方案支持 NIC 或 NVMe 和 GPU 等設備之間的拷貝，它們是 PCIe 總線上的對等設備，以解決這一差距。同時， GDS 帶來的性能提升太大，無法等待上游解決方案傳播到所有用戶。多種供應商提供了支持 GDS 的替代解決方案，包括 MLNX _ OFED （表 2 ）。 GDS 解決方案涉及與 POSIX pread和pwrite類似的新 API cuFileRead或cuFileWrite。

動態路由、 NVLink 的使用以及 CUDA 流中使用的異步 API （僅可從 GDS 獲得）等優化使cuFile API 成為 CUDA 編程模型的持久特性，即使在 Linux 文件系統中的漏洞得到解決之后也是如此。

以下是GDS實現的功能。首先，當前Linux實現的基本問題是通過虛擬文件系統（VFS）向下傳遞 GPU 緩沖區地址作為DMA目標，以便本地NVMe或網絡適配器中的DMA引擎可以執行到 GPU 內存或從 GPU 內存的傳輸。這會導致出現錯誤情況。我們現在有辦法解決這個問題：在 CPU 內存中傳遞一個緩沖區地址。

當使用cuFile API （如cuFileRead或cuFileWrite）時，libcufile。因此，用戶級庫捕獲 GPU 緩沖區地址，并替換傳遞給 VFS 的代理 CPU 緩沖區地址。就在緩沖區地址用于 DMA 之前，啟用 GDS 的驅動程序對nvidia-fs.ko的調用識別 CPU 緩沖區地址，并再次提供替代 GPU 緩沖區地址，以便 DMA 可以正確進行。

libcufile.so中的邏輯執行前面描述的各種優化，如動態路由、預固定緩沖區的使用和對齊。圖 2 顯示了用于此優化的堆棧。cuFile API 是 Magnum IO 靈活抽象體系結構原則的一個示例，它支持特定于平臺的創新和優化，如選擇性緩沖和 NVLink 的使用。

了解更多

GPU 直接存儲帖子是對 GPU 直接存儲的最初介紹。我們向最終客戶和原始設備制造商推薦 NVIDIA GPU 直接存儲設計指南，向最終客戶、原始設備制造商和合作伙伴推薦 NVIDIA GPU 直接存儲概述指南。有關使用 GDS 編程的更多信息，請參閱cuFile API 參考指南。

?