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

Chiplet技術(shù)和NoC技術(shù)目前已經(jīng)成為解決摩爾定律無法延續(xù)的一種重要方法，現(xiàn)在的CPU芯片對外的接口已經(jīng)不是普通的IO了，而是一套標(biāo)準(zhǔn)的NoC總線接口，可以與專門的NoC總線DIE（暫稱為IO DIE）利用Chiplet技術(shù)連接，多個(gè)CPU核或異構(gòu)核與多個(gè)IO DIE再通過Chiplet技術(shù)進(jìn)行集成，就可以做出來更大規(guī)模的芯片。正是Chiplet技術(shù)和NoC技術(shù)的出現(xiàn)給體系結(jié)構(gòu)帶來了發(fā)展的黃金時(shí)代，異構(gòu)計(jì)算和DSA（Domain-Specific Architecture，領(lǐng)域特定體系結(jié)構(gòu)）慢慢走上舞臺，人工智能領(lǐng)域各種高效的架構(gòu)層出不窮，甚至Nvidia最新的Hopper GPU也開始向DSA慢慢靠攏；異構(gòu)計(jì)算的核心之一是互連，傳統(tǒng)的PCIe總線缺乏緩存一致性機(jī)制，導(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之間的接口，并詳細(xì)評估了CCIX與PCIe之間的差異，現(xiàn)將該文章譯文奉上，以饗讀者。

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

01

?

引言

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

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

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

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

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

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

02

?

相關(guān)工作

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

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

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

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

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

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

03

?

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

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

A.總體概述

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

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

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

B.使用 Xilinx XDMA的 FPGA RA

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

C.使用 Xilinx CPM 的 FPGA RA

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

D. 地址翻譯

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

E.? CCIX 時(shí)序模型

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

04

?

實(shí)驗(yàn)設(shè)置和評估

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

A. 測量設(shè)置

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

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

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

B.Low-Level實(shí)驗(yàn)評估

實(shí)驗(yàn) 1：CCIX 與 PCIe - 延遲和吞吐量。

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

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

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

實(shí)驗(yàn) 2：ATS 的成本。

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

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

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

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

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

實(shí)驗(yàn) 3：數(shù)據(jù)局部性。

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

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

實(shí)驗(yàn) 4：一致性努力。

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

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

實(shí)驗(yàn) 5：原子操作。

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

05

?

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

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

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

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

A. 共享鎖表

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

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

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

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

B. 評估

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

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

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

06結(jié)論

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

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

編輯：黃飛

?