Chiplet技術(shù)和NoC技術(shù)目前已經(jīng)成為解決摩爾定律無法延續(xù)的一種重要方法，現(xiàn)在的CPU芯片對外的接口已經(jīng)不是普通的IO了，而是一套標準的NoC總線接口，可以與專門的NoC總線DIE（暫稱為IO DIE）利用Chiplet技術(shù)連接，多個CPU核或異構(gòu)核與多個IO DIE再通過Chiplet技術(shù)進行集成，就可以做出來更大規(guī)模的芯片。正是Chiplet技術(shù)和NoC技術(shù)的出現(xiàn)給體系結(jié)構(gòu)帶來了發(fā)展的黃金時代，異構(gòu)計算和DSA（Domain-Specific Architecture，領(lǐng)域特定體系結(jié)構(gòu)）慢慢走上舞臺，人工智能領(lǐng)域各種高效的架構(gòu)層出不窮，甚至Nvidia最新的Hopper GPU也開始向DSA慢慢靠攏；異構(gòu)計算的核心之一是互連，傳統(tǒng)的PCIe總線缺乏緩存一致性機制，導(dǎo)致內(nèi)存性能低下，延遲低于可接受水平，因此出現(xiàn)了CCIX和CXL等協(xié)議，這些協(xié)議基于PCIe又高于PCIe，在繼承PCIe兼容性的基礎(chǔ)上，又提供了緩存一致性支持。在今年的FCCM會議上，德國TU Darmstadt和Reutlingen University聯(lián)合發(fā)表了一篇CCIX相關(guān)的文章，該文章使用CCIX作為FPGA與Host之間的接口，并詳細評估了CCIX與PCIe之間的差異，現(xiàn)將該文章譯文奉上，以饗讀者。

摘要：長期以來，大多數(shù)分立加速器都使用各代 PCI-Express 接口連接到主機系統(tǒng)。然而，由于缺乏對加速器和主機緩存之間一致性的支持，細粒度的交互需要頻繁的緩存刷新，甚至需要使用低效的非緩存內(nèi)存區(qū)域。加速器緩存一致性互連 (CCIX) 是第一個支持緩存一致性主機加速器附件的多供應(yīng)商標準，并且已經(jīng)表明了即將推出的標準的能力，例如 Compute Express Link (CXL)。在我們的工作中，當基于 ARM 的主機與兩代支持 CCIX 的 FPGA 連接時，我們比較了 CCIX 與 PCIe 的使用情況。我們?yōu)樵L問和地址轉(zhuǎn)換提供低級吞吐量和延遲測量，并檢查使用 CCIX 在 FPGA 加速數(shù)據(jù)庫系統(tǒng)中進行細粒度同步的應(yīng)用級用例。我們可以證明，從 FPGA 到主機的特別小的讀取可以從 CCIX 中受益，因為其延遲比 PCIe 短約 33%。不過，對主機的小寫入延遲大約比 PCIe 高 32%，因為它們攜帶更高的一致性開銷。對于數(shù)據(jù)庫用例，即使在主機-FPGA 并行度很高的情況下，使用 CCIX 也可以保持恒定的同步延遲。

01引言

當將主機 CPU 上基于軟件的傳統(tǒng)處理與專用硬件加速器相結(jié)合以執(zhí)行異構(gòu)計算以獲得更高的性能或更高的效率時，主機和加速器之間接口的性質(zhì)是一個關(guān)鍵的設(shè)計決策。

對于大多數(shù)離散加速器，例如 GPU 或 FPGA 板卡，PCI Express（簡稱：PCIe）長期以來一直是主要的接口。其性能穩(wěn)步提升，最新廣泛部署的 PCIe4.0 版本達到每通道 1.97 GB/s。然而，PCIe 主要針對高吞吐量批量傳輸進行了優(yōu)化。例如，如 [1] 所示，需要 128 到 256 KB 的傳輸才能達到至少 50% 的理論帶寬。對于細粒度主機-加速器交互所需的較小傳輸大小（降至緩存行大?。蓪崿F(xiàn)的吞吐量顯著下降。雖然 PCIe 添加了諸如地址轉(zhuǎn)換服務(wù) (ATS) / 頁面請求接口 (PRI) 之類的擴展來支持共享虛擬內(nèi)存或原子操作，但大多數(shù)實現(xiàn)并不包含緩存一致性機制。

這使得細粒度的交互變得非常昂貴，因為在同步執(zhí)行或交換小參數(shù)或結(jié)果時，主機或加速器端都需要緩存刷新，或者用于數(shù)據(jù)傳輸?shù)膬?nèi)存區(qū)域必須標記為未緩存，從而減慢它們所在物理位置的處理元件（主機或加速器）的訪問速度。

為了解決這個問題，已經(jīng)提出了許多還涵蓋高速緩存一致性的接口和協(xié)議。在這項工作中，我們研究了加速器緩存一致性互連 (CCIX) 的使用，這是第一個被指定為多供應(yīng)商標準并跨多個不同加速器和主機架構(gòu)實現(xiàn)的接口。一旦獲得更廣泛行業(yè)支持的 Compute Express Link (CXL) 等協(xié)議進入市場，預(yù)計在不久的將來會有進一步的改進。

我們提供了各種 CCIX 訪問場景的詳細低級測量，以及應(yīng)用程序級用例。后者在運行利用近數(shù)據(jù)處理 (NDP) 的數(shù)據(jù)庫管理系統(tǒng)(DBMS) 時，采用 CCIX 實現(xiàn) FPGA 加速器和主機之間的高性能同步。據(jù)我們所知，這是第一次為此目的使用緩存一致的加速器接口。

我們將在下一節(jié)中概述一些接口和協(xié)議，然后在第 III 節(jié)中討論 CCIX 細節(jié)，尤其是關(guān)于FPGA加速器的內(nèi)容。不過，我們的主要貢獻是評估，我們在第四節(jié)中介紹了低級特征，在第五節(jié)中介紹了應(yīng)用程序級用例。我們在第六節(jié)中總結(jié)并期待未來的工作。

02相關(guān)工作

a) PCIe：PCI Express [2] 是將外圍設(shè)備連接到桌面和服務(wù)器系統(tǒng)的標準。PCIe 通過為單個設(shè)備捆綁多個通道來擴展鏈路的帶寬。在 1.0 版中，它能夠以每通道 250 MB/s 的速度傳輸。每個后續(xù)版本的帶寬大約翻了一番，現(xiàn)在在 6.0 版本中達到了每通道 7.88 GB/s。目前，6.0 版本剛剛被指定，而 5.0 的硬件即將推出，4.0 是當前硬件上部署最廣泛的版本。PCIe 使用全雙工串行鏈路，采用點對點拓撲結(jié)構(gòu)，在電氣鏈路層之上有兩個附加層，即數(shù)據(jù)鏈路層和事務(wù)層。這些附加層提供糾錯和基于數(shù)據(jù)包的通信。除了傳輸數(shù)據(jù)、設(shè)備初始化等基本操作外，PCIe 還支持更高級（可選）的功能，例如 PRI 和 ATS，但不包括緩存一致性。

b) CCIX：CCIX [3]、[4] 是一種高級 I/O 互連，它使兩個或多個設(shè)備能夠以一致的方式共享數(shù)據(jù)。在物理層上，它可以與PCIe 兼容（盡管它可以選擇允許更高的信令速率），并且僅在協(xié)議和端點控制器上有所不同。它由 CCIX 聯(lián)盟于 2016 年推出，該聯(lián)盟由 AMD、ARM、華為、IBM、Mellanox、高通、賽靈思 [5] 創(chuàng)立。CCIX 已在基于 ARM 和基于 x86 的 CPU 上實現(xiàn)。

c) 其他共享虛擬內(nèi)存 (SVM) 或緩存一致性 SVM 互連：CCIX 并不是共享虛擬內(nèi)存互連的唯一競爭者。阿里巴巴集團、思科系統(tǒng)、戴爾/EMC、Facebook、谷歌、HPE、華為、英特爾和微軟在 2019 年基于英特爾之前的工作提出了 CXL [6]。雖然 CCIX 可以在較舊的 PCIe 連接上運行，但 CXL 最初是基于 PCIe 5.0 設(shè)計的。因此，CXL 可以達到每個通道高達 32 GT/s（即 3.94 GB/s），它提供與 CCIX 類似的功能，但使用不同的邏輯視圖。CXL 已經(jīng)看到比 CCIX 更廣泛的工業(yè)應(yīng)用，并有望成為未來幾年的主要解決方案。

另一種選擇是 IBM 于 2014 年推出的 Coherent Accelerator ProcessorInterface（CAPI，后來的 OpenCAPI）。雖然第一個版本也是在PCIe 之上實現(xiàn)的，但最近的版本是供應(yīng)商特定的接口。CAPI 主要用于基于 IBM POWER 的主機，因此其范圍比CCIX 和 CXL 更有限。在 OpenCAPI 3.0（x8 通道）中，它提供 22 GB/s 的帶寬和 298/80 ns[7] 的讀/寫延遲。

雖然不是像 CCIX 那樣直接擴展 PCIe，但支持緩存一致性協(xié)議的另一個互連是 Gen-Z [8]。它每通道提供高達 56 GT/s 的速度，并允許與 PCIe 類似地組合多個通道。盡管具有令人鼓舞的功能，但尚未商業(yè)發(fā)布 Gen-Z 硬件，該技術(shù)將合并到 CXL中。

d) FPGA 上的數(shù)據(jù)庫加速：[9] 很好地概述了使用 FPGA 加速數(shù)據(jù)庫操作。最常見的方法，例如在 Centaur [10] 等最先進的解決方案中使用的方法，采用 FPGA 作為大規(guī)模過濾、排序、連接或算術(shù)計算的卸載加速器。但是，這種操作模式會帶來大量數(shù)據(jù)從 FPGA 傳輸?shù)?FPGA 的成本，并且與這里研究的旨在避免這些傳輸?shù)慕鼣?shù)據(jù)處理方法不同。

03CCIX架構(gòu)及在FPGA上的使用

本節(jié)將概述通用 CCIX 架構(gòu)，并討論如何在兩個不同的 FPGA 系列中使用它。

A.總體概述

設(shè)備在端點連接到 CCIX。對于這里的討論，相關(guān)類型的端點是歸屬代理 (HA) 和請求代理 (RA)。HA 充當物理內(nèi)存的“所有者”，它提供對物理內(nèi)存的一致訪問，而 RA 通過與擁有的 HA 通信來執(zhí)行對遠程內(nèi)存的非本地讀取和寫入。CCIX 與 PCIe 的區(qū)別在于 RA 可以提供自己的緩存，但通過 CCIX 保持與 HA 的一致性。在 HA 側(cè)，緩存狀態(tài)的變化將通過發(fā)送適當?shù)南鞑サ皆L問的 RA。CCIX 本身使用物理地址進行訪問，但可以選擇使用現(xiàn)有的 PCIe 機制來允許加速器使用虛擬地址。為了執(zhí)行實際的地址轉(zhuǎn)換，CCIX 依賴于 PCIe ATS 機制，這也是 CCIX 附加的加速器也在不同的 PCIe 虛擬通道 (VC) 上保持與主機的傳統(tǒng) PCIe 連接的原因之一。在包括網(wǎng)格和交換層次結(jié)構(gòu)在內(nèi)的各種 CCIX 拓撲中，我們采用了一種簡單的拓撲，它依賴于主機和加速器之間的直接連接。此外，由于硬件接口級別支持所有必需的操作，包括地址轉(zhuǎn)換和一致性，因此主機上不需要特殊的設(shè)備驅(qū)動程序或自定義固件。

圖1 中間 (A)：具有 CCIX 功能的主機的架構(gòu)，充當 HA，附加 CCIX 的加速器充當 RA。 左 (B)：在 Xilinx UltraScale+ HBM 器件上實現(xiàn)CCIX-RA 的 SoC。 右 (C)：在 Versal ACAP 設(shè)備上實現(xiàn) CCIX-RA 的 SoC。

圖 1-(A) 顯示了支持 CCIX 設(shè)備的高速緩存一致性主機 FPGA 附件的高級架構(gòu)。此框圖的頂部是主機，底部是加速器，兩者都通過支持 CCIX 的 PCIe 接口連接。CCIX 在 PCIe 事務(wù)層上使用多個VC，在同一個 PCIe 插槽上傳輸 PCIe 和 CCIX 流量。在支持 CCIX 的插槽上，事務(wù)層對 PCIe 數(shù)據(jù)包使用 VC0，對 CCIX 數(shù)據(jù)包使用 VC1，共享相同的物理層和鏈路層。但是，CCIX 可以選擇使用擴展速度模式 (ESM)，這會增加信令速率。對于我們使用的 PCIe 4.0 附件，ESM 將速率從 16 GT/s 提高到 25 GT/s，每次傳輸 128 個有效負載位。如果雙方（即 RA 和 HA）都支持，ESM 模式將在引導(dǎo)時的 CCIX 發(fā)現(xiàn)階段自動啟用。

B.使用 Xilinx XDMA的 FPGA RA

Xilinx Virtex UltraScale+ HBM 器件支持 CCIX，但必須以擴展 XDMA IP 塊的形式將 CCIX 功能實現(xiàn)為可重新配置的“軟”邏輯。如圖 1-(B) 所示，關(guān)鍵模塊包括一個支持 CCIX 的 PCIe 控制器、一個 ATS 交換機和一個 PCIe-AXIMM 橋。ATS 開關(guān)用于通過 PCIe VC0 將虛擬到物理地址轉(zhuǎn)換請求插入到常規(guī) PCIe 通信中，然后檢索它們的結(jié)果。它還包括一個小的地址轉(zhuǎn)換緩存 (ATC) 來緩沖現(xiàn)有的轉(zhuǎn)換結(jié)果，以避免對已知映射進行相對昂貴的地址轉(zhuǎn)換。AXIMM 橋提供主機和加速器之間的內(nèi)存映射通信（主要是控制平面流量）。對于數(shù)據(jù)平面訪問，加速器采用了使用賽靈思系統(tǒng)緩存 IP 塊 [11] 實現(xiàn)的片上緩存，該緩存又使用 CCIX 流協(xié)議與 CCIX 一致性機制交互。此緩存中的未命中成為遠程內(nèi)存訪問，通過 CCIX 轉(zhuǎn)發(fā)到 HA 以檢索數(shù)據(jù)。反過來，HA 確保了 FPGA 端 SC 與主機端緩存的一致性。

C.使用 Xilinx CPM 的 FPGA RA

最新的 Xilinx Versal 器件在其芯片中優(yōu)化了對 CCIX 的“強化”支持。具體來說，一致性和 PCIe 模塊 (CPM) IP 塊 [12] 包括一個集成的 L2 緩存，使用ARM的CHI協(xié)議與芯片范圍內(nèi)的一致性網(wǎng)狀網(wǎng)絡(luò)通信，后者又使用CXS 與支持 CCIX 的 PCIe 控制器接口。與之前在UltraScale+設(shè)備中一樣，兩個 PCIeVC 用于分離在同一PCIe插槽上運行的PCIe和CCIX流量。我們的設(shè)置只需要CPM模塊提供的兩個支持CCIX的PCIe 控制器之一。ATS Switch 和 AXIMM 塊與以前一樣使用。

D. 地址翻譯

在系統(tǒng)緩存 (SC) 收到來自加速器的讀/寫請求后，它會檢查 ATC 的虛擬到物理映射。如果 SC 在 ATC 中沒有找到有效的轉(zhuǎn)換（即ATC未命中），它會通過 VC0 使用 PCIe ATS 功能向主機請求轉(zhuǎn)換。系統(tǒng)緩存上的 ATS 接口使用請求完成協(xié)議 [13] 通過四個流接口提供翻譯服務(wù)：傳入完成者請求 (CQ)、傳出完成者完成 (CC)、傳出請求者請求 (RQ) 和傳入請求者完成（RC）。來自主機的回復(fù)（例如，保留物理地址）使用相同的機制傳遞回 FPGA。

E. CCIX 時序模型

CCIX 事務(wù)的平均延遲如公式 1 所示。每個事務(wù)的延遲取決于ATC中可用的有效緩存地址轉(zhuǎn)換的概率與ATS必須從主機請求新轉(zhuǎn)換的概率，以及所請求的數(shù)據(jù)是否存在于本地片上緩存中。必須從遠程 HA 請求。請注意，使用 ESM 時，物理 CCIX 延遲可能比物理 PCIe 延遲更短。

04實驗設(shè)置和評估

我們在真實硬件中進行實際評估，即使用支持 CCIX 的 ARM N1-SDP 平臺作為主機，使用分別具有UltraScale+ HBM 和 Versal ACAP FPGA Xilinx 的Alveo U280 (AU280) 和 VCK5000 CCIX附加板作為加速器。表I顯示了不同設(shè)備的規(guī)格。

A. 測量設(shè)置

稍后描述的所有低級基準測試都使用相同的基本測量方法，該方法由三個主要組件組成：軟件應(yīng)用程序編程接口 (API)、硬件模塊和上述片上 CCIX 組件。軟件 API 在主機上運行，負責執(zhí)行基準測試并讀取硬件分析的 CCIX 延遲特性。軟件 API 有四個主要任務(wù)：a) 在主機內(nèi)存中分配緩沖區(qū)，b) 初始化硬件模塊以訪問測量，c) 檢索硬件模塊記錄的延遲數(shù)據(jù)，以及 d) 分析結(jié)果。軟件 API 的偽代碼如算法 1 所示。請注意，我們將地址隨機化以強制 SC 未命中，從而確保我們感興趣的 CCIX 傳輸實際發(fā)生。

稱為 CCIX 流量生成器 (CTG) 的硬件模塊使用獲取/存儲方法來捕獲 CCIX延遲。該模塊接受來自主機中軟件API的 startTrans 調(diào)用的請求（包括類型、虛擬地址和長度）。在 API 請求之后，CTG 通過 AXI4-MM 接口向 SC 創(chuàng)建請求，SC 執(zhí)行 CCIX RA 的角色，然后計算響應(yīng)到達 SC 的時間。然后可以通過軟件 API 讀取捕獲的時序。請注意，我們僅在其所有數(shù)據(jù)到達后才認為事務(wù)完成。

表II 顯示了我們檢查的簡單 CCIX-RA 所需的 FPGA 資源。如圖 1-(C) 所示，VCK5000 使用硬化 CPM 模塊形式的 PCIe 控制器，但仍需要一些額外的“軟”邏輯來支持 PCIe 傳輸和 ATS 轉(zhuǎn)換。

B.Low-Level實驗評估

實驗 1：CCIX 與 PCIe - 延遲和吞吐量。

在這個實驗中，我們比較了細粒度交互中相對較小的塊大小（32B 到 16KiB）的 CCIX 和 PCIe 傳輸延遲（并且比 [1] 中檢查的 PCIe 批量傳輸要小得多）。開源 TaPaSCo[14] 框架用于測試 DMA 傳輸。在這個實驗中，通過確保地址轉(zhuǎn)換已經(jīng)存在于ATC中來消除 ATS 延遲。圖 2-(A) 和圖 2-(B) 分別顯示了 PCIe 和 CCIX 流量的讀取和寫入延遲。對于 PCIe-DMA 傳輸，我們使用TaPaSCo 的高性能 DMA 引擎，通過設(shè)置不同的數(shù)據(jù)傳輸大小，直接使用主機內(nèi)存數(shù)據(jù)的物理地址。對于 CCIX 測量，在主機內(nèi)存中分配一個緩沖區(qū)，并將其虛擬地址傳遞給 CTG 模塊。

圖2 比較 AU280 和 VCK5000 上的 CCIX 和 PCIe 讀/寫訪問延遲

我們的評估表明，在AU280和VCK5000上，與 PCIe-DMA 傳輸相比，CCIX 傳輸具有更好的主機讀取延遲，只要傳輸?shù)臄?shù)據(jù)短于 4 KiB。在這兩種情況下，加速都是由于 CCIX 使用的優(yōu)化數(shù)據(jù)包協(xié)議。但是，當使用優(yōu)化的數(shù)據(jù)包協(xié)議從 FPGA 寫入主機存儲器時，CCIX 會產(chǎn)生比 PCIe 傳輸更長的延遲，因為這些寫入?yún)⑴c了一致性機制。我們的吞吐量測量顯示，對于 1KiB、16KiB 和 32KiB 的數(shù)據(jù)集大小，CCIX 的讀取吞吐量相對于 PCIe 分別為 3.3x、1.29x、0.87x。讀取和寫入吞吐量的其他數(shù)據(jù)點顯示在表 III 中。

實驗 2：ATS 的成本。

透明地解析虛擬地址的能力大大簡化了加速器設(shè)計和主機接口。但是，該操作可能代價高昂，因為如果請求的轉(zhuǎn)換不存在于主機 IOMMU 的 TLB 之一中，它可能會觸發(fā)主機上緩慢的完整頁表遍歷。在實驗 1 中，我們檢查了不需要地址轉(zhuǎn)換 (noATS) 的訪問。但是為了檢查 ATS 的成本，我們現(xiàn)在構(gòu)建了兩個訪問場景，如圖 3 所示：在第一個場景中（使用 ATS），我們強制在 SC 和 ATC 中未命中，因此總是會產(chǎn)生 ATS 開銷。在第二個（noATS）中，我們允許 ATC 命中，但仍然強制 SC 未命中，以便實際發(fā)生 CCIX 事務(wù)。結(jié)果表明，特別是對于較小的傳輸，ATS 開銷可能很大，導(dǎo)致 ATC 未命中時的訪問延遲增加三倍。但是，對于 32KB 及以上的傳輸，傳輸時間開始主導(dǎo) ATS 開銷。

圖3 ATS 對從 Alveo U280 卡和 VCK5000 上的 CTG 模塊隨機訪問 RA 模塊的 CCIX 訪問延遲的影響

為了進一步研究 ATS 延遲，我們可以利用整個 ATS 機制在 SoC 的 ATS Switch 塊中實現(xiàn)的事實。因此，我們可以監(jiān)控該模塊的請求/回復(fù)接口，以捕獲 ATS 操作本身的確切請求-響應(yīng)時間。圖4顯示了 64 B（高速緩存行大?。?28 B 和 4 KiB 塊的 CCIX 訪問延遲。由于 Linux Page Size 為 4KiB，因此這些請求每個只需要一個 ATS 轉(zhuǎn)換。通過增加請求的大小，需要更多的翻譯。對主機內(nèi)存中分配的緩沖區(qū)的初始訪問具有最長的延遲。以后的順序訪問具有較少的 ATS 開銷，即使在 4 KiB 跨到另一個頁面時也是如此。我們假設(shè)這是由于主機 IOMMU 對此處使用的順序訪問執(zhí)行了預(yù)翻譯。對于重復(fù) 64 B 讀取的情況，通過比較主機 IOMMU 響應(yīng) ATS 請求所需的延遲（≈ 617 ns，在 ATS 交換機處捕獲），以及在 SC 未命中情況下讀取 64B 的已知延遲（≈ 700 ns，來自圖 3-(A)），ATC 本身似乎需要 (2453 - 617 - 700 ≈ 1136 ns) 進行操作。

圖4 比較 Alveo U280 卡上 CCIX-RA 的讀/寫延遲和 ATS 延遲

改善 CCIX 流量延遲的一種方法是減輕地址轉(zhuǎn)換的影響。例如，這可以通過使用Linux大頁面支持來實現(xiàn)。這將導(dǎo)致更大的頁面，進而需要新翻譯的頁面邊界交叉更少。N1-SDP平臺在啟動時確實支持不同大?。?64KB、2MB、32MB 和 1GB）的巨頁。我們在數(shù)據(jù)庫用例（第 V 節(jié)）中采用了這種方法來提高性能。

實驗 3：數(shù)據(jù)局部性。

CCIX 的使用允許加速器使用自己的緩存，確信它們將始終與主機保持一致。為了展示兩個 SoC 的最佳情況基線性能，我們評估了保證所有訪問都在設(shè)備上緩存中命中的情況，在圖 5 中稱為本地數(shù)據(jù)，并測量這些命中的延遲。為了比較，我們還展示了覆蓋緩存未命中的數(shù)據(jù)遠程案例。AU280 中更簡單的緩存層次結(jié)構(gòu)實現(xiàn)了比 VCK5000 上的二級緩存（寫入 ≈150 ns，讀取 ≈ 170 ns）更小的延遲（寫入 ≈ 80 ns，讀取 ≈ 100 ns），以實現(xiàn)更小的傳輸大小。但是，對于較大的傳輸，兩級層次結(jié)構(gòu)變得更快。

圖5 數(shù)據(jù)局部性對 AU280 和 VCK5000 的 CCIX 延遲的影響

實驗 4：一致性努力。

在這種情況下，主機上的應(yīng)用程序分配一個共享緩沖區(qū)，主機和加速器同時訪問和修改該緩沖區(qū)。這些并發(fā)訪問/修改增加了一致性工作，進而增加了訪問延遲。大頁面用于避免 ATS 開銷。如算法 2 所述，硬件 CTG 和軟件 API 同時修改共享緩沖區(qū)中的緩存行。最初，我們使用 2 MiB 的緩沖區(qū)進行測量，然后分別縮小到 512 KiB、128 KiB 和 32 KiB，以增加爭用程度，從而增加保持一致性所需的努力。緩沖區(qū)的這種縮小顯示在圖 6 左側(cè)的 Y 軸上。對于這些共享緩沖區(qū)大小中的每一個，我們使用單個 CPU 內(nèi)核和 FPGA 從兩個主機對緩沖區(qū)中的隨機地址執(zhí)行 1024 次訪問，并跟蹤它們的延遲。正如預(yù)期的那樣，隨著訪問次數(shù)的增加以及緩沖區(qū)大小的縮小，爭用都會增加。在這兩種情況下，必須解決的一致性沖突的可能性都會增加。有趣的是，額外的一致性工作主要影響主機的訪問，F(xiàn)PGA 端訪問的延遲幾乎保持不變。這在圖 6 的右側(cè)進行了更詳細的檢查，該圖繪制了訪問時間的直方圖，現(xiàn)在為 20,000 次訪問，對于 32 KiB 和 2 MiB 共享緩沖區(qū)大小。雖然時間更長，但來自 FPGA 端的遠程訪問比本地主機端訪問的“抖動”（分布更窄）要少得多。請注意，F(xiàn)PGA 端訪問的非常短的異常值實際上是 SC 中的命中，其概率在較小的 32 KiB 中大于在較大的共享緩沖區(qū)中。在這個實驗中，主機上只有一個內(nèi)核訪問共享緩沖區(qū)。為了進一步調(diào)查，我們使用主機上的多個內(nèi)核來修改和訪問共享緩沖區(qū)。我們的評估表明，由于更多的緩存命中，將 32 KiB 地址范圍的內(nèi)核數(shù)量從 1 個增加到 3 個實際上將本地主機端平均訪問延遲從 333 ns 縮短到 235 ns。另一方面，由于更多的緩存未命中，設(shè)備訪問延遲從 674 ns 增長到 741 ns。對于更大的內(nèi)存范圍，訪問時間將再次保持幾乎恒定。

圖6 使用單個 CPU 內(nèi)核增加主機-FPGA 訪問爭用的一致性工作。左 (A)：在從 2 MiB 縮小到 32 KiB 的地址范圍內(nèi)同時進行1024 次隨機訪問。右 (B)：直方圖顯示兩個地址范圍的訪問延遲“抖動”。

實驗 5：原子操作。

CCIX 還能夠通過支持AtomicStore、AtomicLoad、AtomicSwap 和AtomicCompare 操作在 RA（例如 AU280）和 HA（例如 N1-SDP）之間執(zhí)行原子事務(wù)。它們在RA 端構(gòu)建為 AXI4-MM 請求的多步序列。我們的評估表明，從主機啟動的 AtomicCompare 需要 50 ns，而從加速器啟動的 AtomicCompare 需要 740-800 ns。

05數(shù)據(jù)庫應(yīng)用

在這些詳細的低級別測量之后，我們現(xiàn)在檢查 CCIX 在應(yīng)用程序級別的使用，用于需要細粒度主機加速器交互的場景。作為一個現(xiàn)實場景，我們選擇了數(shù)據(jù)庫加速領(lǐng)域。所研究的系統(tǒng)是 neoDBMS（圖 7）[15]、[16]，一種基于 PostgreSQL 的 DBMS，使用 FPGA 加速的 NDP。以這種方式，計算被移到更靠近存儲（例如，閃存、NVM）的地方，假設(shè)存儲直接連接到 加速器。使用 NDP 可減少數(shù)據(jù)傳輸并提高整體系統(tǒng)性能。然而，數(shù)據(jù)庫應(yīng)用程序中的 NDP 面臨一些挑戰(zhàn)，例如同步和事務(wù)一致性。在數(shù)據(jù)庫中，NDP模式下的事務(wù)有兩種，只讀NDP和更新NDP。在只讀NDP中，為了使事務(wù)免于干預(yù)，每個事務(wù)都針對自己的快照進行操作。這需要首先收集主機主內(nèi)存中的所有 DBMS 更新，然后在每次 NDP 調(diào)用 [15] 時將更改的 DBMS 狀態(tài)傳送到加速器。

圖7 具有共享鎖表的 neoDBMS 架構(gòu)

在更新 NDP 中，由于主機和加速器對同一記錄的并發(fā)修改，使事務(wù)免干預(yù)具有挑戰(zhàn)性。最初，相同的當前版本記錄存在于加速器和 DBMS 的內(nèi)存中。如果兩者同時創(chuàng)建記錄的新后繼版本，則會導(dǎo)致兩個當前版本分支，從而導(dǎo)致無法解決的不一致，稱為寫入/寫入沖突。減輕這種不一致性的一種方法是在執(zhí)行之前以獨占方式鎖定整個數(shù)據(jù)庫表，但這會嚴重限制并發(fā)性。另一種方法是使用支持記錄級鎖定的細粒度緩存一致性共享鎖表，從而可以鎖定每條記錄的版本，以同步 DBMS 和加速器之間的修改。

A. 共享鎖表

為了在 DBMS 和加速器之間實現(xiàn)一致且無干預(yù)的更新 NDP 操作，需要低延遲的緩存一致性失效和同步機制。為了處理上述neoDBMS中的寫/寫沖突，我們通過采用基于CCIX的解決方案來實現(xiàn)共享鎖表。如果沒有 CCIX，同步的成本會高得多，并且很可能會浪費 NDP 處理所獲得的任何性能增益。為此，我們修改后的 neoDBMS 在主機內(nèi)存中分配了一個共享鎖表，主機和 FPGA 雙方在更新記錄之前請求鎖定記錄。neoDBMS 依靠 Linux 內(nèi)核中的大頁面（即HugeTLB Page）支持來請求物理上連續(xù)的內(nèi)存頁面，用于分配鎖表并確保它們被固定。由于鎖表的大小相對較小，并且在 DBMS 的整個運行時間內(nèi)都非常頻繁地訪問條目，因此將表固定在物理主機內(nèi)存中是有效的。

通過在位于哈希桶中的隊列中插入一個條目來執(zhí)行獲取行級鎖。因此，隊列可以同時包含多個鎖條目。通過對記錄版本標識符應(yīng)用哈希函數(shù)來計算存儲桶位置。圖 8 顯示了兩個并發(fā)進程的示例，一個在主機上，一個在設(shè)備上，請求相同記錄版本（即 Rv2）的鎖。對記錄版本標識符應(yīng)用哈希函數(shù)會導(dǎo)致兩個進程嘗試將鎖插入位于同一哈希桶中的同一鎖定隊列中，此處編號為 2。在此示例中，首先，設(shè)備請求鎖并立即獲取鎖.第一個槽代表當前持有鎖并且允許修改數(shù)據(jù)的進程。稍后，主機嘗試也請求相同的鎖。由于鎖隊列的第一個槽已經(jīng)被占用，主機無法獲取鎖，并將其請求附加到鎖隊列的尾部并等待。一旦設(shè)備完成，它通過將整個隊列向左移動來釋放鎖，將現(xiàn)在位于隊列頭的鎖授予下一個進程。然后主機獲取鎖并且可以繼續(xù)執(zhí)行。

圖8 共享鎖表中的單個哈希桶（用于哈希鍵 2）的示例，來自主機和設(shè)備的并發(fā)鎖請求在桶中排隊等待相同的記錄版本。

在 FPGA 上，已經(jīng)開發(fā)了一個 Bluespec 模塊來處理來自NDP-update 模塊的鎖定請求。該模塊在提供的虛擬地址上創(chuàng)建一個哈希表組織的鎖表。分配的緩沖區(qū)地址和鎖表由 neoDBMS 指定。模塊通過流接口接收/發(fā)送鎖定請求/響應(yīng)。收到鎖請求后，模塊會創(chuàng)建 CCIX 原子比較和交換 (CAS) 操作來放置鎖并更新隊列，然后AU280 上的 CCIX-RA 將其發(fā)送給主機。通過緩存一致性共享鎖表和所采用的CCIX原子操作，我們實現(xiàn)了DBMS和FPGA之間數(shù)據(jù)的細粒度協(xié)同處理。

B. 評估

為了評估基于 CCIX 的同步機制的性能，我們測量了在 N1-SDP 平臺和基于 AU280 的加速器上運行的 neoDBMS 的端到端鎖定請求延遲，如圖9 所示。由于共享鎖表的大小大于Linux 4KiB 頁面，因此訪問會產(chǎn)生較長的 ATS 開銷的風險很高。這已經(jīng)通過使用大頁面來避免。硬件模塊執(zhí)行一個獨立于實際共享鎖操作的請求，以通過對大頁面的物理轉(zhuǎn)換來“預(yù)熱”ATC。然后，所有實際的鎖定請求都會有 ATC 命中，并且不會受到 ATS 開銷的影響。

圖9 并行訪問共享鎖表的影響

在實驗中，neoDBMS（在單個 CPU 內(nèi)核上）和加速器都會不斷地創(chuàng)建鎖請求，而我們在另一側(cè)增加了爭用。在低競爭下，neoDBMS 能夠在 80 ns 內(nèi)鎖定本地駐留鎖表中的記錄版本。在高競爭下，neoDBMS 的本地鎖定延遲增加到200-250 ns。從加速器鎖定當然需要更長的時間，因為遠程訪問是對主機內(nèi)存執(zhí)行的，但觀察到的 750 到 800 ns 的延遲是 CCIX 原子 CAS 操作的典型延遲（參見上面的實驗 5），最重要的是，不受競爭增加的影響。雖然這證實了上面實驗 4 中已經(jīng)觀察到的行為，但有趣的是，它不僅適用于實驗 4 的簡單讀/寫操作，還適用于此處使用的更復(fù)雜的原子 CAS 訪問。

06結(jié)論

我們研究了使用 CCIX 在主機和基于 FPGA 的加速器之間進行細粒度交互。在我們的結(jié)果中，我們表明，尤其是對于較小的傳輸塊大小，與 PCIe 相比，可以實現(xiàn)更短的延遲。此外，地址轉(zhuǎn)換與 CCIX 操作的透明集成支持主機和 FPGA 加速器之間的緩存一致共享虛擬內(nèi)存 (ccSVM) 編程模型，該模型傳統(tǒng)上僅適用于高度專業(yè)化的平臺，例如 Convey HC 級機器。對于數(shù)據(jù)庫用例，可以看出 CCIX 遠程訪問雖然比本地訪問慢，但即使對鎖表等共享數(shù)據(jù)結(jié)構(gòu)的更高程度的競爭訪問也不會受到影響。

從我們的結(jié)果也可以看出，優(yōu)化潛力存在于硬件/軟件協(xié)議棧的多個級別。例如，我們已經(jīng)演示了使用大頁面來減少地址轉(zhuǎn)換開銷。還可以在 SoC 中插入更有效的特定于應(yīng)用程序的翻譯機制，因為所有翻譯都發(fā)生在 ATSSwitch 模塊中，該模塊具有良好記錄的接口，可以用自定義版本替換。這可以被利用，例如，在 Sec.V 的 DBMS 用例中，即使對于超過 ATC 容量的隨機訪問模式，也可以完全避免 ATS。ATC 本身似乎也有優(yōu)化潛力，但這需要更大的工程努力，因為它與供應(yīng)商提供的系統(tǒng)黑盒部分更緊密地集成在一起。

審核編輯：湯梓紅