0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

使用CCIX進(jìn)行高速緩存一致性主機(jī)到FPGA接口的評(píng)估

FPGA技術(shù)江湖 ? 來源:網(wǎng)絡(luò)交換FPGA ? 2023-06-29 09:56 ? 次閱讀

Chiplet技術(shù)和NoC技術(shù)目前已經(jīng)成為解決摩爾定律無法延續(xù)的一種重要方法,現(xiàn)在的CPU芯片對(duì)外的接口已經(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))慢慢走上舞臺(tái),人工智能領(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會(huì)議上,德國TU Darmstadt和Reutlingen University聯(lián)合發(fā)表了一篇CCIX相關(guān)的文章,該文章使用CCIX作為FPGA與Host之間的接口,并詳細(xì)評(píng)估了CCIX與PCIe之間的差異,現(xiàn)將該文章譯文奉上,以饗讀者。

摘要:長期以來,大多數(shù)分立加速器都使用各代 PCI-Express 接口連接到主機(jī)系統(tǒng)。然而,由于缺乏對(duì)加速器和主機(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)換提供低級(jí)吞吐量和延遲測(cè)量,并檢查使用 CCIX 在 FPGA 加速數(shù)據(jù)庫系統(tǒng)中進(jìn)行細(xì)粒度同步的應(yīng)用級(jí)用例。我們可以證明,從 FPGA 到主機(jī)的特別小的讀取可以從 CCIX 中受益,因?yàn)槠溲舆t比 PCIe 短約 33%。不過,對(duì)主機(jī)的小寫入延遲大約比 PCIe 高 32%,因?yàn)樗鼈償y帶更高的一致性開銷。對(duì)于數(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ì)決策。

對(duì)于大多數(shù)離散加速器,例如 GPU 或 FPGA 板卡,PCI Express(簡稱:PCIe)長期以來一直是主要的接口。其性能穩(wěn)步提升,最新廣泛部署的 PCIe4.0 版本達(dá)到每通道 1.97 GB/s。然而,PCIe 主要針對(duì)高吞吐量批量傳輸進(jìn)行了優(yōu)化。例如,如 [1] 所示,需要 128 到 256 KB 的傳輸才能達(dá)到至少 50% 的理論帶寬。對(duì)于細(xì)粒度主機(jī)-加速器交互所需的較小傳輸大?。ń抵辆彺嫘写笮。?,可實(shí)現(xiàn)的吞吐量顯著下降。雖然 PCIe 添加了諸如地址轉(zhuǎn)換服務(wù) (ATS) / 頁面請(qǐng)求接口 (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ì)在不久的將來會(huì)有進(jìn)一步的改進(jìn)。

我們提供了各種 CCIX 訪問場景的詳細(xì)低級(jí)測(cè)量,以及應(yīng)用程序級(jí)用例。后者在運(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)是評(píng)估,我們?cè)诘谒墓?jié)中介紹了低級(jí)特征,在第五節(jié)中介紹了應(yīng)用程序級(jí)用例。我們?cè)诘诹?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)對(duì)點(diǎn)拓?fù)浣Y(jié)構(gòu),在電氣鏈路層之上有兩個(gè)附加層,即數(shù)據(jù)鏈路層和事務(wù)層。這些附加層提供糾錯(cuò)和基于數(shù)據(jù)包的通信。除了傳輸數(shù)據(jù)、設(shè)備初始化等基本操作外,PCIe 還支持更高級(jí)(可選)的功能,例如 PRI 和 ATS,但不包括緩存一致性。

b) CCIX:CCIX [3]、[4] 是一種高級(jí) 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ì)算的卸載加速器。但是,這種操作模式會(huì)帶來大量數(shù)據(jù)從 FPGA 傳輸?shù)?FPGA 的成本,并且與這里研究的旨在避免這些傳輸?shù)慕鼣?shù)據(jù)處理方法不同。

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

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

A.總體概述

設(shè)備在端點(diǎn)連接到 CCIX。對(duì)于這里的討論,相關(guān)類型的端點(diǎn)是歸屬代理 (HA) 和請(qǐng)求代理 (RA)。HA 充當(dāng)物理內(nèi)存的“所有者”,它提供對(duì)物理內(nèi)存的一致訪問,而 RA 通過與擁有的 HA 通信來執(zhí)行對(duì)遠(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ī)和加速器之間的直接連接。此外,由于硬件接口級(jí)別支持所有必需的操作,包括地址轉(zhuǎn)換和一致性,因此主機(jī)上不需要特殊的設(shè)備驅(qū)動(dòng)程序或自定義固件。

6de0e286-1601-11ee-962d-dac502259ad0.png

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

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)換請(qǐng)求插入到常規(guī) PCIe 通信中,然后檢索它們的結(jié)果。它還包括一個(gè)小的地址轉(zhuǎn)換緩存 (ATC) 來緩沖現(xiàn)有的轉(zhuǎn)換結(jié)果,以避免對(duì)已知映射進(jìn)行相對(duì)昂貴的地址轉(zhuǎn)換。AXIMM 橋提供主機(jī)和加速器之間的內(nèi)存映射通信(主要是控制平面流量)。對(duì)于數(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)化了對(duì) 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) 收到來自加速器的讀/寫請(qǐng)求后,它會(huì)檢查 ATC 的虛擬到物理映射。如果 SC 在 ATC 中沒有找到有效的轉(zhuǎn)換(即ATC未命中),它會(huì)通過 VC0 使用 PCIe ATS 功能向主機(jī)請(qǐng)求轉(zhuǎn)換。系統(tǒng)緩存上的 ATS 接口使用請(qǐng)求完成協(xié)議 [13] 通過四個(gè)流接口提供翻譯服務(wù):傳入完成者請(qǐng)求 (CQ)、傳出完成者完成 (CC)、傳出請(qǐng)求者請(qǐng)求 (RQ) 和傳入請(qǐng)求者完成(RC)。來自主機(jī)的回復(fù)(例如,保留物理地址)使用相同的機(jī)制傳遞回 FPGA。

E. CCIX 時(shí)序模型

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

6e2c705c-1601-11ee-962d-dac502259ad0.png

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

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

6e7eff84-1601-11ee-962d-dac502259ad0.png

A. 測(cè)量設(shè)置

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

6eb0ed50-1601-11ee-962d-dac502259ad0.png

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

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

6ef2685c-1601-11ee-962d-dac502259ad0.png

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

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

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

6f231f88-1601-11ee-962d-dac502259ad0.png

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

我們的評(píng)估表明,在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ī)存儲(chǔ)器時(shí),CCIX 會(huì)產(chǎn)生比 PCIe 傳輸更長的延遲,因?yàn)檫@些寫入?yún)⑴c了一致性機(jī)制。我們的吞吐量測(cè)量顯示,對(duì)于 1KiB、16KiB 和 32KiB 的數(shù)據(jù)集大小,CCIX 的讀取吞吐量相對(duì)于 PCIe 分別為 3.3x、1.29x、0.87x。讀取和寫入吞吐量的其他數(shù)據(jù)點(diǎn)顯示在表 III 中。

6f501e02-1601-11ee-962d-dac502259ad0.png

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

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

6fa923f8-1601-11ee-962d-dac502259ad0.png

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

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

6ffe899c-1601-11ee-962d-dac502259ad0.png

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

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

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

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

70453658-1601-11ee-962d-dac502259ad0.png

圖5 數(shù)據(jù)局部性對(duì) 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)行測(cè)量,然后分別縮小到 512 KiB、128 KiB 和 32 KiB,以增加爭用程度,從而增加保持一致性所需的努力。緩沖區(qū)的這種縮小顯示在圖 6 左側(cè)的 Y 軸上。對(duì)于這些共享緩沖區(qū)大小中的每一個(gè),我們使用單個(gè) CPU 內(nèi)核和 FPGA 從兩個(gè)主機(jī)對(duì)緩沖區(qū)中的隨機(jī)地址執(zhí)行 1024 次訪問,并跟蹤它們的延遲。正如預(yù)期的那樣,隨著訪問次數(shù)的增加以及緩沖區(qū)大小的縮小,爭用都會(huì)增加。在這兩種情況下,必須解決的一致性沖突的可能性都會(huì)增加。有趣的是,額外的一致性工作主要影響主機(jī)的訪問,F(xiàn)PGA 端訪問的延遲幾乎保持不變。這在圖 6 的右側(cè)進(jìn)行了更詳細(xì)的檢查,該圖繪制了訪問時(shí)間的直方圖,現(xiàn)在為 20,000 次訪問,對(duì)于 32 KiB 和 2 MiB 共享緩沖區(qū)大小。雖然時(shí)間更長,但來自 FPGA 端的遠(yuǎn)程訪問比本地主機(jī)端訪問的“抖動(dòng)”(分布更窄)要少得多。請(qǐng)注意,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ū)。我們的評(píng)估表明,由于更多的緩存命中,將 32 KiB 地址范圍的內(nèi)核數(shù)量從 1 個(gè)增加到 3 個(gè)實(shí)際上將本地主機(jī)端平均訪問延遲從 333 ns 縮短到 235 ns。另一方面,由于更多的緩存未命中,設(shè)備訪問延遲從 674 ns 增長到 741 ns。對(duì)于更大的內(nèi)存范圍,訪問時(shí)間將再次保持幾乎恒定。

709164f6-1601-11ee-962d-dac502259ad0.png

70d5284e-1601-11ee-962d-dac502259ad0.png

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

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

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

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

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

713ed816-1601-11ee-962d-dac502259ad0.png

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

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

A. 共享鎖表

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

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

716e474a-1601-11ee-962d-dac502259ad0.png

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

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

B. 評(píng)估

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

71b699b4-1601-11ee-962d-dac502259ad0.png

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

在實(shí)驗(yàn)中,neoDBMS(在單個(gè) CPU 內(nèi)核上)和加速器都會(huì)不斷地創(chuàng)建鎖請(qǐng)求,而我們?cè)诹硪粋?cè)增加了爭用。在低競爭下,neoDBMS 能夠在 80 ns 內(nèi)鎖定本地駐留鎖表中的記錄版本。在高競爭下,neoDBMS 的本地鎖定延遲增加到200-250 ns。從加速器鎖定當(dāng)然需要更長的時(shí)間,因?yàn)檫h(yuǎn)程訪問是對(duì)主機(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é)果中,我們表明,尤其是對(duì)于較小的傳輸塊大小,與 PCIe 相比,可以實(shí)現(xiàn)更短的延遲。此外,地址轉(zhuǎn)換與 CCIX 操作的透明集成支持主機(jī)和 FPGA 加速器之間的緩存一致共享虛擬內(nèi)存 (ccSVM) 編程模型,該模型傳統(tǒng)上僅適用于高度專業(yè)化的平臺(tái),例如 Convey HC 級(jí)機(jī)器。對(duì)于數(shù)據(jù)庫用例,可以看出 CCIX 遠(yuǎn)程訪問雖然比本地訪問慢,但即使對(duì)鎖表等共享數(shù)據(jù)結(jié)構(gòu)的更高程度的競爭訪問也不會(huì)受到影響。

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

審核編輯:湯梓紅

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • FPGA
    +關(guān)注

    關(guān)注

    1620

    文章

    21510

    瀏覽量

    598919
  • 接口
    +關(guān)注

    關(guān)注

    33

    文章

    8257

    瀏覽量

    149953
  • 加速器
    +關(guān)注

    關(guān)注

    2

    文章

    785

    瀏覽量

    37149
  • chiplet
    +關(guān)注

    關(guān)注

    6

    文章

    404

    瀏覽量

    12513
收藏 人收藏

    評(píng)論

    相關(guān)推薦

    如何解決數(shù)據(jù)庫與緩存一致性

    緩存一致性 每次逢年過節(jié)的時(shí)候搶票非常艱難,放票的時(shí)候那么多人同時(shí)去搶票,如果所有人查詢、購票等都去訪問數(shù)據(jù)庫,那數(shù)據(jù)庫的壓力得有多大,這時(shí)候很多都會(huì)引入緩存, 把車票信息放入緩存,這
    的頭像 發(fā)表于 09-25 15:25 ?909次閱讀
    如何解決數(shù)據(jù)庫與<b class='flag-5'>緩存</b><b class='flag-5'>一致性</b>

    高速緩存/海量緩存的設(shè)計(jì)實(shí)現(xiàn)

    /D轉(zhuǎn)換結(jié)果并進(jìn)行處理。高速緩存IS61LV25616的數(shù)據(jù)總線方面連到FPGA以便在采樣期間接受復(fù)用的A/D轉(zhuǎn)換結(jié)果;方面則通過三態(tài)門
    發(fā)表于 12-04 15:59

    改進(jìn)的基于目錄的Cache一致性協(xié)議

    介紹幾種典型目錄一致性協(xié)議并分析它們的優(yōu)缺點(diǎn)。在綜合全映射目錄和有限目錄優(yōu)點(diǎn)的基礎(chǔ)上,通過在存儲(chǔ)器層上增加個(gè)存儲(chǔ)器高速緩存(Cache)層的方式,提出并討論種改進(jìn)后
    發(fā)表于 04-02 09:05 ?32次下載

    C64x+ DSP高速緩存一致性分析與維護(hù)

    C64x+ DSP高速緩存一致性分析與維護(hù) 高速緩存(CACHE)作為內(nèi)核和低速存儲(chǔ)器之間的橋梁,基于代碼和數(shù)據(jù)的時(shí)間和空間相關(guān),以塊為單位由硬件控制器自動(dòng)加載內(nèi)核所需
    發(fā)表于 01-04 12:00 ?1395次閱讀
    C64x+ DSP<b class='flag-5'>高速緩存</b><b class='flag-5'>一致性</b>分析與維護(hù)

    基于C64x+ DSP高速緩存一致性分析

    的運(yùn)行機(jī)制,內(nèi)核始終能夠得到存儲(chǔ)器中最新的數(shù)據(jù)。但是當(dāng)有其它可以更改存儲(chǔ)器內(nèi)容的部件存在時(shí),例如不需要內(nèi)核干預(yù)的直接數(shù)據(jù)存?。―MA)引擎,就可能出現(xiàn)由于CACHE的存在而導(dǎo)致內(nèi)核或者DMA不能夠得到最新數(shù)據(jù)的現(xiàn)象,也就是CACHE一致性的問題
    發(fā)表于 10-25 16:16 ?0次下載
    基于C64x+ DSP<b class='flag-5'>高速緩存</b><b class='flag-5'>一致性</b>分析

    加速器一致性接口

    提供異步緩存一致性直接訪問PS的入口。處理器可以標(biāo)記ACP上的傳輸為一致性或非一致性。PL端的AXI主機(jī)通過ARUSERS[1:0]指示是否
    發(fā)表于 11-17 15:04 ?3474次閱讀

    Cache一致性協(xié)議優(yōu)化研究

    問題的由來.總結(jié)了多核時(shí)代高速緩存一致性協(xié)議設(shè)計(jì)的關(guān)鍵問題,綜述了近年來學(xué)術(shù)界對(duì)一致性的研究.從程序訪存行為模式、目錄組織結(jié)構(gòu)、一致性粒度、一致性
    發(fā)表于 12-30 15:04 ?0次下載
    Cache<b class='flag-5'>一致性</b>協(xié)議優(yōu)化研究

    自主駕駛系統(tǒng)將使用緩存一致性互連IP和非一致性互連IP

    代ASIL B(D)自主駕駛系統(tǒng)將使用符合ISO 26262標(biāo)準(zhǔn)的緩存一致性互連IP和非一致性互連IP來實(shí)現(xiàn)。 美國加利福尼亞州坎貝爾2019年4月26日消息—Arteris IP
    的頭像 發(fā)表于 05-09 17:13 ?3115次閱讀

    談CPU緩存緩存一致性

    左圖為最簡單的高速緩存的配置,數(shù)據(jù)的讀取和存儲(chǔ)都經(jīng)過高速緩存,CPU核心與高速緩存條特殊的快速通道;主存與高速緩存都連在系統(tǒng)總線上(BU
    的頭像 發(fā)表于 05-03 17:51 ?2088次閱讀
    談<b class='flag-5'>一</b>談CPU<b class='flag-5'>緩存</b>和<b class='flag-5'>緩存</b><b class='flag-5'>一致性</b>

    管理基于Cortex?-M7的MCU的高速緩存一致性

    本文檔概述了不同場景下的高速緩存一致性問題,并就如何管理或避免高速緩存一致性問題提供了些方法建議。
    發(fā)表于 04-01 10:12 ?5次下載
    管理基于Cortex?-M7的MCU的<b class='flag-5'>高速緩存</b><b class='flag-5'>一致性</b>

    使用MPLAB Harmony v3基于PIC32MZ MCU在運(yùn)行時(shí)使用高速緩存維護(hù)操作處理高速緩存一致性問題

    電子發(fā)燒友網(wǎng)站提供《使用MPLAB Harmony v3基于PIC32MZ MCU在運(yùn)行時(shí)使用高速緩存維護(hù)操作處理高速緩存一致性問題.pdf》資料免費(fèi)下載
    發(fā)表于 09-19 16:28 ?0次下載
    使用MPLAB Harmony v3基于PIC32MZ MCU在運(yùn)行時(shí)使用<b class='flag-5'>高速緩存</b>維護(hù)操作處理<b class='flag-5'>高速緩存</b><b class='flag-5'>一致性</b>問題

    利用MPLAB Harmony v3在Cortex-M7 MCU上在運(yùn)行時(shí)使用高速緩存維護(hù)操作處理高速緩存一致性問題

    電子發(fā)燒友網(wǎng)站提供《利用MPLAB Harmony v3在Cortex-M7 MCU上在運(yùn)行時(shí)使用高速緩存維護(hù)操作處理高速緩存一致性問題.pdf》資料免費(fèi)下載
    發(fā)表于 09-20 11:40 ?0次下載
    利用MPLAB Harmony v3在Cortex-M7 MCU上在運(yùn)行時(shí)使用<b class='flag-5'>高速緩存</b>維護(hù)操作處理<b class='flag-5'>高速緩存</b><b class='flag-5'>一致性</b>問題

    管理基于Cortex-M7的MCU的高速緩存一致性

    電子發(fā)燒友網(wǎng)站提供《管理基于Cortex-M7的MCU的高速緩存一致性.pdf》資料免費(fèi)下載
    發(fā)表于 09-25 10:11 ?0次下載
    管理基于Cortex-M7的MCU的<b class='flag-5'>高速緩存</b><b class='flag-5'>一致性</b>

    如何保證緩存一致性

    “ 本文的參考文章是2022年HOT 34上Intel Rob Blakenship關(guān)于CXL緩存一致性篇介紹?!?/div>
    的頭像 發(fā)表于 10-19 17:42 ?855次閱讀
    如何保證<b class='flag-5'>緩存</b><b class='flag-5'>一致性</b>

    Redis緩存與Mysql如何保證一致性?

    基本流程就是客戶端A請(qǐng)求,先去刪除緩存,然后將數(shù)據(jù)寫入數(shù)據(jù)庫,此時(shí)客戶端B查詢先去查詢緩存,緩存沒有返回,去查數(shù)據(jù)庫,此時(shí)還沒有完成主從同步,拿到是從庫的舊數(shù)據(jù),然后將舊數(shù)據(jù)進(jìn)行
    的頭像 發(fā)表于 12-02 14:23 ?817次閱讀
    Redis<b class='flag-5'>緩存</b>與Mysql如何保證<b class='flag-5'>一致性</b>?