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

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

01

?

引言

當將主機 CPU 上基于軟件的傳統處理與專用硬件加速器相結合以執行異構計算以獲得更高的性能或更高的效率時，主機和加速器之間接口的性質是一個關鍵的設計決策。

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

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

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

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

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

02

?

相關工作

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

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

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

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

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

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

03

?

CCIX架構及在FPGA上的使用

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

A.總體概述

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

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

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

B.使用 Xilinx XDMA的 FPGA RA

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

C.使用 Xilinx CPM 的 FPGA RA

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

D. 地址翻譯

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

E.? CCIX 時序模型

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

04

?

實驗設置和評估

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

A. 測量設置

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

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

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

B.Low-Level實驗評估

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

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

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

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

實驗 2：ATS 的成本。

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

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

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

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

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

實驗 3：數據局部性。

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

圖5 數據局部性對 AU280 和 VCK5000 的 CCIX 延遲的影響

實驗 4：一致性努力。

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

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

實驗 5：原子操作。

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

05

?

數據庫應用

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

圖7 具有共享鎖表的 neoDBMS 架構

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

A. 共享鎖表

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

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

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

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

B. 評估

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

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

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

06結論

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

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

編輯：黃飛

?