利用CXL技術(shù)重構(gòu)基于RDMA的內(nèi)存解耦合

內(nèi)存解耦合（memory disaggregation）是一種前景廣闊的現(xiàn)代數(shù)據(jù)中心架構(gòu)，將計(jì)算和內(nèi)存資源分開為獨(dú)立的資源池，通過超高速網(wǎng)絡(luò)連接，可提高內(nèi)存利用率、降低成本，并實(shí)現(xiàn)計(jì)算和內(nèi)存資源的彈性擴(kuò)展。然而，現(xiàn)有基于遠(yuǎn)程直接內(nèi)存訪問（RDMA）的內(nèi)存解耦合解決方案存在較高的延遲和額外開銷，包括頁面錯(cuò)誤和代碼重構(gòu)。新興的緩存一致性互連技術(shù)（如CXL）為重構(gòu)高性能內(nèi)存解耦合提供了機(jī)會。然而，現(xiàn)有基于CXL的方法存在物理距離限制，并且無法跨機(jī)架部署。

本文提出了一種基于RDMA和CXL的新型低延遲、高可擴(kuò)展性的內(nèi)存解耦合系統(tǒng)Rcmp。其顯著特點(diǎn)是通過CXL提高了基于RDMA系統(tǒng)的性能，并利用RDMA克服了CXL的距離限制。為解決RDMA和CXL在粒度、通信和性能方面的不匹配，Rcmp：（1）提供基于全局頁面的內(nèi)存空間管理，實(shí)現(xiàn)細(xì)粒度數(shù)據(jù)訪問；（2）設(shè)計(jì)了一種有效的通信機(jī)制，避免了通信阻塞問題；（3）提出了一種熱頁識別和交換策略，減少了RDMA通信；（4）設(shè)計(jì)了一個(gè)RDMA優(yōu)化的RPC框架，加速了RDMA傳輸。我們實(shí)現(xiàn)了Rcmp的原型，并通過微基準(zhǔn)測試和運(yùn)行帶有YCSB基準(zhǔn)測試的鍵值存儲來評估其性能。結(jié)果顯示，Rcmp比基于RDMA的系統(tǒng)的延遲降低了5.2倍，吞吐量提高了3.8倍。我們還證明，Rcmp可以隨著節(jié)點(diǎn)數(shù)量的增加而良好擴(kuò)展，而不會影響性能。

01.?引言

內(nèi)存解耦合在數(shù)據(jù)中心（例如，RSA [48]，WSC [5]和dReD-Box [27]），云服務(wù)器（例如，Pond [30]和Amazon Aurora [53]），內(nèi)存數(shù)據(jù)庫（例如，PolarDB [11]和LegoBase [65]）以及高性能計(jì)算（HPC）系統(tǒng) [37, 55]等領(lǐng)域越來越受青睞，因?yàn)樗梢蕴岣哔Y源利用率、靈活的硬件可擴(kuò)展性和降低成本。這種架構(gòu)（見圖1）將計(jì)算和內(nèi)存資源從傳統(tǒng)的單體服務(wù)器中解耦，形成獨(dú)立的資源池。計(jì)算池包含豐富的CPU資源但最少的內(nèi)存資源，而內(nèi)存池包含大量內(nèi)存但幾乎沒有計(jì)算能力。內(nèi)存解耦合可以提供全局共享內(nèi)存池，并允許不同資源獨(dú)立擴(kuò)展，為構(gòu)建成本效益和彈性數(shù)據(jù)中心提供了機(jī)會。

圖1. 內(nèi)存解耦合

圖2. 不同的內(nèi)存解耦合架構(gòu)

遠(yuǎn)程直接內(nèi)存訪問（RDMA）網(wǎng)絡(luò)通常被采用在內(nèi)存解耦合系統(tǒng)中連接計(jì)算和內(nèi)存池（見圖2(a)）。然而，現(xiàn)有基于RDMA的內(nèi)存解耦合解決方案存在顯著缺陷。一個(gè)是高延遲。當(dāng)前的RDMA可以支持單位數(shù)微秒級別的延遲（1.5～3 μs）[17, 64]，但仍然比DRAM內(nèi)存延遲（80～140 ns）相差幾個(gè)數(shù)量級。RDMA通信成為訪問內(nèi)存池的性能瓶頸。另一個(gè)是額外的開銷。由于內(nèi)存語義不是原生支持的，RDMA在原系統(tǒng)上產(chǎn)生了侵入性的代碼修改和中斷開銷。具體來說，當(dāng)前基于RDMA的內(nèi)存解耦合包括基于頁面和基于對象的方法，根據(jù)數(shù)據(jù)交換粒度的不同而不同。然而，基于頁面的方法涉及額外的頁面錯(cuò)誤處理和讀/寫放大開銷 [10, 41]，而基于對象的方法則需要定制接口更改和源代碼級別的修改，這會犧牲透明度 [17, 56]。

CXL（Compute Express Link）是一種基于PCIe的緩存一致性互連協(xié)議，它能夠?qū)崿F(xiàn)對遠(yuǎn)程內(nèi)存設(shè)備的直接和一致訪問，無需CPU干預(yù)[45, 52]。CXL原生支持內(nèi)存語義，并具有類似多插槽NUMA訪問延遲（約90～150 ns [21, 45]）的特性，具有克服RDMA缺點(diǎn)、實(shí)現(xiàn)低成本、高性能內(nèi)存解耦合的潛力。近年來，基于CXL的內(nèi)存解耦合技術(shù)在學(xué)術(shù)界和工業(yè)界引起了廣泛關(guān)注[10, 21, 30, 56]。

重構(gòu)基于CXL的內(nèi)存解耦合架構(gòu)（見圖2(b)）以取代RDMA是一項(xiàng)有前景的研究，但是CXL技術(shù)的不成熟和缺乏工業(yè)級產(chǎn)品使其在實(shí)踐中變得困難。首先，存在物理限制?，F(xiàn)有基于CXL的內(nèi)存解耦合面臨著長距離部署的限制，通常僅限于數(shù)據(jù)中心內(nèi)部的機(jī)架級別，即使對于最新的CXL 3.0規(guī)范也是如此[14, 45, 56]。物理距離限制導(dǎo)致無法在機(jī)架之間部署內(nèi)存池，失去了高度可擴(kuò)展性。其次，成本高昂。用CXL硬件替換數(shù)據(jù)中心中的所有RDMA硬件的成本非常高昂，特別是對于大規(guī)模集群而言。此外，由于缺乏商業(yè)化的大規(guī)模生產(chǎn)的CXL硬件和支持基礎(chǔ)設(shè)施，目前對CXL內(nèi)存的研究依賴于定制的FPGA原型[21, 49]或者使用無CPU NUMA節(jié)點(diǎn)進(jìn)行仿真[30, 32]。

在本文中，我們探討了一種結(jié)合了CXL和RDMA的混合內(nèi)存解耦合架構(gòu)，旨在保留并利用RDMA，使CXL能夠打破距離約束。在這樣的架構(gòu)中（見圖2(c)），在一個(gè)機(jī)架中建立一個(gè)小型基于CXL的內(nèi)存池，使用RDMA連接機(jī)架，形成一個(gè)更大的內(nèi)存池。這種方法利用CXL提高基于RDMA的內(nèi)存解耦合的性能，并忽略了CXL的物理距離限制。然而，它在實(shí)施過程中面臨著巨大挑戰(zhàn)，包括RDMA和CXL的粒度不匹配、通信不匹配和性能不匹配（第3.3節(jié)）。特別是，由于RDMA和CXL之間的延遲差距，機(jī)架之間的RDMA通信成為主要的性能瓶頸。一些研究提出了一種基于RDMA驅(qū)動的加速框架[61]，使用緩存一致性加速器連接到類似CXL的緩存一致性內(nèi)存，但這種方法需要定制的硬件。

為解決這些問題，我們提出了一種新穎的基于RDMA和CXL的內(nèi)存解耦合系統(tǒng)Rcmp，提供低延遲和可擴(kuò)展的內(nèi)存池服務(wù)。如圖2(c)所示，Rcmp的顯著特點(diǎn)是將基于RDMA的方法（見圖2(a)）和基于CXL的方法（見圖2(b)）結(jié)合起來，以克服兩者的缺點(diǎn)，并最大化CXL的性能優(yōu)勢。Rcmp提出了幾個(gè)優(yōu)化設(shè)計(jì)來解決上述挑戰(zhàn)。具體來說，Rcmp具有四個(gè)關(guān)鍵特性。首先，Rcmp提供全局內(nèi)存分配和地址管理，將數(shù)據(jù)移動大?。ň彺嫘辛６龋┡c內(nèi)存分配大小（頁面粒度）解耦。細(xì)粒度數(shù)據(jù)訪問可以避免IO放大 [10, 56]。其次，Rcmp設(shè)計(jì)了一種高效的機(jī)架內(nèi)和機(jī)架間通信機(jī)制，以避免通信阻塞問題。第三，Rcmp提出了一種熱頁識別和交換策略，以及一種CXL內(nèi)存緩存策略和同步機(jī)制，以減少機(jī)架間的訪問。第四，Rcmp設(shè)計(jì)了一個(gè)高性能的RDMA感知RPC框架，加速機(jī)架間的RDMA傳輸。

我們以6483行C++代碼實(shí)現(xiàn)了Rcmp作為用戶級架構(gòu)。Rcmp為內(nèi)存池服務(wù)提供了簡單的API，易于應(yīng)用程序使用。此外，Rcmp通過與FUSE [1]集成，提供了簡單的高容量內(nèi)存文件系統(tǒng)接口。我們使用微基準(zhǔn)測試評估了Rcmp，并在YCSB工作負(fù)載下運(yùn)行了一個(gè)鍵值存儲（哈希表）。評估結(jié)果表明，Rcmp在所有工作負(fù)載下均實(shí)現(xiàn)了高性能和穩(wěn)定性。具體而言，與基于RDMA的內(nèi)存解耦合系統(tǒng)相比，Rcmp在微基準(zhǔn)測試下將延遲降低了3到8倍，在YCSB工作負(fù)載下將吞吐量提高了2到4倍。此外，隨著節(jié)點(diǎn)或機(jī)架數(shù)量的增加，Rcmp具有良好的可擴(kuò)展性。本文中Rcmp的開源代碼和實(shí)驗(yàn)數(shù)據(jù)集可在https://github.com/PDS-Lab/Rcmp 上獲取。

總之，我們的工作主要貢獻(xiàn)如下：

分析了當(dāng)前內(nèi)存解耦合系統(tǒng)的缺點(diǎn)，指出基于RDMA的系統(tǒng)存在高延遲、額外開銷和通信不佳的問題，而基于CXL的系統(tǒng)受到物理距離限制和缺乏可用產(chǎn)品的影響。

設(shè)計(jì)并實(shí)現(xiàn)了Rcmp，一個(gè)新穎的內(nèi)存池系統(tǒng)，通過結(jié)合RDMA和CXL的優(yōu)勢，實(shí)現(xiàn)了高性能和可擴(kuò)展性。據(jù)我們所知，這是第一個(gè)利用RDMA和CXL技術(shù)構(gòu)建內(nèi)存解耦合架構(gòu)的工作。

提出了許多優(yōu)化設(shè)計(jì)，以克服將RDMA和CXL結(jié)合時(shí)遇到的性能挑戰(zhàn)，包括全局內(nèi)存管理、高效的通信機(jī)制、熱頁交換策略和高性能RPC框架。

對Rcmp的性能進(jìn)行了全面評估，并與最先進(jìn)的內(nèi)存解耦合系統(tǒng)進(jìn)行了比較。結(jié)果表明，Rcmp在性能和可擴(kuò)展性方面明顯優(yōu)于這些系統(tǒng)。

本文的其余部分組織如下。第2和第3節(jié)介紹了背景和動機(jī)。第4和第5節(jié)介紹了Rcmp的設(shè)計(jì)思想和系統(tǒng)架構(gòu)細(xì)節(jié)。第6節(jié)展示了全面的評估結(jié)果。第7節(jié)總結(jié)了相關(guān)工作。第8節(jié)對全文進(jìn)行了總結(jié)。

02.?背景

2.1 內(nèi)存解耦合 新興應(yīng)用程序，如大數(shù)據(jù)[31, 39]，深度學(xué)習(xí)[4, 28]，HPC[37, 55]，以及大型語言模型（例如，ChatGpt[7]和GPT-3[19]），在現(xiàn)代數(shù)據(jù)中心中越來越普遍，這導(dǎo)致了對內(nèi)存的巨大需求[2, 3, 44, 56]。然而，當(dāng)今的數(shù)據(jù)中心主要使用單體服務(wù)器架構(gòu)，其中CPU和內(nèi)存緊密耦合，面臨著日益增長的內(nèi)存需求帶來的重大挑戰(zhàn)： 低內(nèi)存利用率：在單體服務(wù)器中，由于單個(gè)實(shí)例占用的內(nèi)存資源無法跨服務(wù)器邊界分配，很難充分利用內(nèi)存資源。表1顯示，典型數(shù)據(jù)中心、云平臺和HPC系統(tǒng)的內(nèi)存利用率通常低于50%。此外，實(shí)際應(yīng)用程序經(jīng)常請求大量內(nèi)存，但實(shí)際上內(nèi)存并未充分利用。例如，在Microsoft Azure和Google的集群中[30, 33, 56]，分配的內(nèi)存約有30%到61%長時(shí)間處于空閑狀態(tài)。

表1. 典型系統(tǒng)中的內(nèi)存利用率 彈性不足：在單體服務(wù)器中安裝內(nèi)存或CPU資源后，很難對其進(jìn)行縮小/擴(kuò)大。因此，服務(wù)器配置必須事先規(guī)劃，并且動態(tài)調(diào)整通常會導(dǎo)致現(xiàn)有服務(wù)器硬件的浪費(fèi)[44, 65]。此外，由于固定的CPU到內(nèi)存比率，很難將單個(gè)服務(wù)器的內(nèi)存容量靈活地?cái)U(kuò)展到所需大小[44, 56]。

成本高昂：大量未使用的內(nèi)存資源導(dǎo)致運(yùn)營成本高和能源浪費(fèi)[11, 65]。此外，現(xiàn)代數(shù)據(jù)中心設(shè)備故障頻繁，幾乎每天都會發(fā)生[13, 40, 58]。采用單體架構(gòu)時(shí)，當(dāng)服務(wù)器內(nèi)的任何一個(gè)硬件組件發(fā)生故障時(shí)，通常整個(gè)服務(wù)器無法使用。這種粗粒度的故障管理導(dǎo)致了高昂的成本[44]。 為應(yīng)對這些問題，提出了內(nèi)存解耦合的方案，并在學(xué)術(shù)界和工業(yè)界引起了廣泛關(guān)注[3, 17, 21, 43, 51, 56, 63, 66]。內(nèi)存解耦合將數(shù)據(jù)中心中的內(nèi)存資源與計(jì)算資源分離開來，形成通過快速網(wǎng)絡(luò)連接的獨(dú)立資源池。這使得不同資源可以獨(dú)立管理和擴(kuò)展，實(shí)現(xiàn)了更高的內(nèi)存利用率、彈性擴(kuò)展和降低成本。 如圖1所示，在這樣的架構(gòu)中，計(jì)算池中的計(jì)算節(jié)點(diǎn)（CNs）包含大量的CPU核心和少量的本地DRAM，而內(nèi)存池中的內(nèi)存節(jié)點(diǎn)（MNs）則托管大容量內(nèi)存，幾乎沒有計(jì)算能力。微秒級延遲網(wǎng)絡(luò)（例如，RDMA）或緩存一致性互連協(xié)議（例如，CXL）通常是從CNs到MNs的物理傳輸方式。

2.2 RDMA技術(shù) RDMA是一系列允許一臺計(jì)算機(jī)直接訪問網(wǎng)絡(luò)中其它計(jì)算機(jī)數(shù)據(jù)的協(xié)議。RDMA協(xié)議通常直接固化在RDMA網(wǎng)卡（RNIC）上，并且具有高帶寬（>10 GB/s）和微秒級低延遲（～2 μs），被InfiniBand、RoCE、OmniPath等廣泛支持 [20, 47, 62]。RDMA提供基于兩種操作原語的數(shù)據(jù)傳輸服務(wù)：單邊操作包括RDMA READ、WRITE、ATOMIC（例如，F(xiàn)AA、CAS），雙邊操作包括RDMA SEND、RECV。RDMA通信是通過一個(gè)消息隊(duì)列模型實(shí)現(xiàn)的，稱為隊(duì)列對（QP）和完成隊(duì)列（CQ）。QP包括發(fā)送隊(duì)列（SQ）和接收隊(duì)列（RQ）。發(fā)送方將請求提交到SQ（單邊或雙邊操作），而RQ用于在雙邊操作中排隊(duì)RDMA RECV請求。CQ與指定的QP關(guān)聯(lián)。同一SQ中的請求按順序執(zhí)行。通過使用門鈴批處理（doorbell batching） [47, 64]，多個(gè)RDMA操作可以合并為單個(gè)請求。然后，這些請求由RNIC讀取，RNIC異步地從遠(yuǎn)程內(nèi)存中寫入或讀取數(shù)據(jù)。當(dāng)發(fā)送方的請求完成時(shí)，RNIC將完成條目寫入CQ，以便發(fā)送方可以通過輪詢CQ來知道完成情況。

2.3 CXL協(xié)議 CXL是一種基于PCIe的開放行業(yè)標(biāo)準(zhǔn)，用于處理器、加速器和內(nèi)存之間的高速通信，采用Load/Store語義以緩存一致的方式進(jìn)行。CXL包含三種獨(dú)立的協(xié)議，包括CXL.io、CXL.cache和CXL.mem。其中，CXL.mem允許CPU通過PCIe總線（FlexBus）直接訪問底層內(nèi)存，而無需涉及頁面錯(cuò)誤或DMA。因此，CXL可以在相同的物理地址空間中提供字節(jié)可尋址的內(nèi)存（CXL內(nèi)存），并允許透明內(nèi)存分配。使用PCIe 5.0，CPU到CXL互連帶寬將類似于NUMA體系結(jié)構(gòu)中的跨NUMA互連。從軟件的角度來看，CXL內(nèi)存可以被視為一個(gè)無CPU的NUMA節(jié)點(diǎn)，訪問延遲也與NUMA訪問延遲相似（約為90～150 ns [21, 45]）。甚至CXL 3.0規(guī)范 [45] 報(bào)告稱，CXL.mem的訪問延遲接近于普通DRAM（約為40-ns讀延遲和80-ns寫延遲）。然而，大多數(shù)論文中使用的當(dāng)前CXL原型的訪問延遲明顯更高，約為170到250 ns [30, 32, 49]。

03.?現(xiàn)有內(nèi)存解耦合架構(gòu)及其局限性

3.1 基于RDMA的方法

基于RDMA的內(nèi)存解耦合可大致分為兩種方式：基于頁面（page based）和基于對象（object based）。基于頁面的方法（如Infiniswap [22]，LegoOS [44]，F(xiàn)astswap [3]）使用虛擬內(nèi)存機(jī)制將內(nèi)存池中的遠(yuǎn)程頁面緩存在本地DRAM中。它通過觸發(fā)頁面故障和交換本地內(nèi)存頁面和遠(yuǎn)程頁面來實(shí)現(xiàn)對遠(yuǎn)程內(nèi)存池的訪問。優(yōu)點(diǎn)在于其簡單易用，并對應(yīng)用程序透明。基于對象的方法（如FaRM [17]，F(xiàn)aRMV2 [43]，AIFM [41]，Gengar [18]）通過定制的對象語義（如鍵值接口）實(shí)現(xiàn)細(xì)粒度的內(nèi)存管理。單邊操作使得計(jì)算節(jié)點(diǎn)可以直接訪問內(nèi)存節(jié)點(diǎn)，而無需涉及遠(yuǎn)程CPU，這更適合于內(nèi)存解耦合，因?yàn)閮?nèi)存節(jié)點(diǎn)幾乎沒有計(jì)算能力。然而，如果在內(nèi)存解耦合系統(tǒng)中僅使用單邊RDMA原語進(jìn)行通信，單個(gè)數(shù)據(jù)查詢可能涉及多次讀寫操作，導(dǎo)致延遲較高 [25, 26]。因此，許多研究提出了基于RDMA的高性能RPC框架（如FaSST [26]，F(xiàn)aRM [17]）或采用不涉及RDMA原語的通用RPC庫 [24]。

圖3. 通信測試

表2. 延遲比較 基于RDMA的方法存在以下缺點(diǎn)。

問題1：高延遲。RDMA通信和內(nèi)存訪問之間存在較大的延遲差異，超過20倍。這使得RDMA網(wǎng)絡(luò)成為基于RDMA的內(nèi)存解耦合系統(tǒng)的主要性能瓶頸。

問題2：高開銷。基于頁面的方法由于頁面故障開銷而性能下降。例如，F(xiàn)astswap [3]具有較高的遠(yuǎn)程訪問延遲。此外，對于細(xì)粒度訪問，會發(fā)生讀/寫放大，因?yàn)閿?shù)據(jù)始終以頁面粒度傳輸?；趯ο蟮姆椒梢员苊忭撁婀收祥_銷，但需要進(jìn)行侵入式的代碼修改，并且根據(jù)應(yīng)用程序的語義而變化，導(dǎo)致復(fù)雜性更高。

問題3：通信不佳。現(xiàn)有的RDMA通信方法未充分利用RDMA帶寬。我們使用主流通信框架（包括（1）僅RPC（使用eRPC [24]），以及（2）單邊RDMA和RPC混合模式[17, 26]）測試了不同數(shù)據(jù)大小的吞吐量。結(jié)果表明，RPC通信適用于小數(shù)據(jù)傳輸，而混合模式在大數(shù)據(jù)場景下具有更高的吞吐量。512字節(jié)是一個(gè)分界點(diǎn)，這啟發(fā)我們設(shè)計(jì)動態(tài)策略?？傊?，基于RDMA的解決方案總結(jié)如表3所示。

3.2 基于CXL的方法 許多研究提出了使用CXL的內(nèi)存解耦合架構(gòu)，以克服基于RDMA的方法的缺點(diǎn)，并實(shí)現(xiàn)更低的訪問延遲?；贑XL的內(nèi)存解耦合可以提供共享的緩存一致性內(nèi)存池，并支持緩存行粒度訪問，而無需進(jìn)行侵入性更改?？偟膩碚f，基于CXL的方法相對于基于RDMA的方法具有以下優(yōu)勢：

較少的軟件開銷：CXL在主機(jī)處理器（CPU）和任何連接的CXL設(shè)備上的內(nèi)存之間維護(hù)統(tǒng)一的一致性內(nèi)存空間?；贑XL的方法減少了軟件堆棧的復(fù)雜性，避免了頁面故障開銷。

細(xì)粒度訪問：CXL支持CPU、GPU和其它處理器通過原生Load/Store指令訪問內(nèi)存池。基于CXL的方法允許緩存行粒度訪問，避免了基于RDMA的方法的讀/寫放大問題。

低延遲：CXL提供接近內(nèi)存的延遲，基于CXL的方法緩解了網(wǎng)絡(luò)瓶頸和內(nèi)存過度配置的問題。

彈性：基于CXL的方法具有出色的可擴(kuò)展性，因?yàn)榭梢赃B接更多的PCIe設(shè)備，而不像用于DRAM的DIMM（雙列直插式內(nèi)存模塊）那樣受限。 然而，基于CXL的方法也存在以下缺點(diǎn)。

問題1：物理距離限制。由于PCIe總線長度有限，基于CXL的方法在機(jī)架級別內(nèi)受限（現(xiàn)有的CXL產(chǎn)品最大距離為2米），無法直接應(yīng)用于大規(guī)模數(shù)據(jù)中心?？梢允褂肞CIe靈活延長網(wǎng)線，但仍存在最大長度限制。一個(gè)正在進(jìn)行的研究工作是將PCIe 5.0電信號轉(zhuǎn)換為光信號，目前仍處于測試階段，需要專門的硬件。這種方法也存在潛在的開銷，包括信號損失、功耗、部署成本等。在3到4米的距離上，僅光傳輸時(shí)間就超過了現(xiàn)代內(nèi)存的首字節(jié)訪問延遲。因此，如果基于CXL的內(nèi)存解耦合超出機(jī)架邊界，將會對延遲敏感的應(yīng)用程序產(chǎn)生明顯影響。

問題2：高成本。當(dāng)前CXL產(chǎn)品尚未成熟，大多數(shù)研究仍處于仿真階段，包括基于FPGA的原型和使用NUMA節(jié)點(diǎn)的模擬。早期使用FPGA的CXL產(chǎn)品尚未針對延遲進(jìn)行優(yōu)化，并且報(bào)告的延遲較高。因此，NUMA基礎(chǔ)的模擬仍然是CXL概念驗(yàn)證的更流行方法。此外，當(dāng)前CXL產(chǎn)品的昂貴價(jià)格使得將數(shù)據(jù)中心中的所有RDMA硬件替換為CXL硬件變得不切實(shí)際。

3.3 混合方法和挑戰(zhàn) 一種可能的解決方案是利用網(wǎng)絡(luò)來克服CXL的機(jī)架距離限制。最先進(jìn)的案例是CXL-over-Ethernet。它將計(jì)算和內(nèi)存池部署在不同的機(jī)架中，并在計(jì)算池中使用CXL提供全局一致內(nèi)存抽象，因此CPU可以通過Load/Store語義直接訪問分離的內(nèi)存。然后，采用以太網(wǎng)來傳輸CXL內(nèi)存訪問請求到內(nèi)存池。這種方法可以支持緩存行訪問粒度，但每個(gè)遠(yuǎn)程訪問仍然需要網(wǎng)絡(luò)，并且無法利用CXL的低延遲。正在進(jìn)行的優(yōu)化是在CXL內(nèi)存中仔細(xì)設(shè)計(jì)緩存策略。表3顯示了現(xiàn)有內(nèi)存解耦合方法的比較，它們都有優(yōu)點(diǎn)和局限性。

表3. 內(nèi)存解耦合方法比較

正如許多研究人員認(rèn)為的那樣，CXL和RDMA是互補(bǔ)的技術(shù)，將兩者結(jié)合起來是有前途的研究。在本文中，我們通過結(jié)合基于CXL和基于RDMA的方法（即，在機(jī)架內(nèi)通過CXL構(gòu)建小型內(nèi)存池，并通過RDMA連接這些小型內(nèi)存池）來探索一種新的混合架構(gòu)。這種對稱架構(gòu)允許在每個(gè)小型內(nèi)存池中充分利用CXL的優(yōu)勢，并通過RDMA提高可擴(kuò)展性。然而，這種混合架構(gòu)面臨以下挑戰(zhàn)。

挑戰(zhàn)1：粒度不匹配。基于CXL的方法支持以緩存行為訪問粒度的緩存一致性?；赗DMA的方法的訪問粒度是頁面或?qū)ο?，比緩存行粒度大得多。需要為混合架?gòu)重新設(shè)計(jì)內(nèi)存管理和訪問機(jī)制。

挑戰(zhàn)2：通信不匹配。RDMA通信依賴于RNIC和消息隊(duì)列，而CXL基于高速鏈路和緩存一致性協(xié)議。需要實(shí)現(xiàn)統(tǒng)一和高效的抽象，以用于機(jī)架內(nèi)和機(jī)架間的通信。

挑戰(zhàn)3：性能不匹配。RDMA的延遲遠(yuǎn)遠(yuǎn)大于CXL（超過10倍）。性能不匹配將導(dǎo)致非統(tǒng)一的訪問模式（類似于NUMA架構(gòu)）——即，訪問本地機(jī)架內(nèi)存（本地機(jī)架訪問）比訪問遠(yuǎn)程機(jī)架內(nèi)存（遠(yuǎn)程機(jī)架訪問）要快得多。

04.?設(shè)計(jì)思路

為了解決這些挑戰(zhàn)，我們提出了 Rcmp，一種新型的混合內(nèi)存池系統(tǒng)，采用 RDMA 和 CXL。如表3所示，Rcmp 實(shí)現(xiàn)了更好的性能和可擴(kuò)展性。主要的設(shè)計(jì)權(quán)衡和思路如下所述。

4.1 全局內(nèi)存管理 Rcmp 通過基于頁面的方法實(shí)現(xiàn)全局內(nèi)存管理，原因有兩點(diǎn)。首先，頁面管理方法易于采用，并對所有用戶應(yīng)用程序透明。其次，基于頁面的方法更適合 CXL 的字節(jié)訪問特性，而對象基方法則帶來額外的索引開銷。每個(gè)頁面被劃分為許多 slab 以進(jìn)行細(xì)粒度管理。此外，Rcmp 為內(nèi)存池提供全局地址管理，并最初使用集中式元數(shù)據(jù)服務(wù)器（MS）來管理內(nèi)存地址的分配和映射。 Rcmp 以緩存行粒度訪問和移動數(shù)據(jù)，與內(nèi)存頁面大小解耦。由于 CXL 支持內(nèi)存語義，Rcmp 可以自然地在機(jī)架內(nèi)以緩存行粒度進(jìn)行訪問。對于遠(yuǎn)程機(jī)架訪問，Rcmp 避免了性能下降，采用直接訪問模式（Direct-I/O）而不是由頁面錯(cuò)誤觸發(fā)的頁面交換。

4.2 高效通信機(jī)制 如圖4所示，混合架構(gòu)有三種遠(yuǎn)程機(jī)架通信的可選方法。在方法（a）中，每個(gè)計(jì)算節(jié)點(diǎn)通過自己的 RNIC 訪問遠(yuǎn)程機(jī)架中的內(nèi)存池。這種方法有明顯的缺點(diǎn)。首先是高昂的成本，由于過多的 RNIC 設(shè)備；其次，每個(gè)計(jì)算節(jié)點(diǎn)都有 CXL 鏈接和 RDMA 接口，導(dǎo)致高一致性維護(hù)開銷；第三，與有限的 RNIC 內(nèi)存存在高競爭，導(dǎo)致頻繁的緩存失效和更高的通信延遲。在方法（b）中，每個(gè)機(jī)架上都使用一個(gè)守護(hù)進(jìn)程服務(wù)器（配備有 RNIC）來管理對遠(yuǎn)程機(jī)架的訪問請求。守護(hù)進(jìn)程服務(wù)器可以降低成本和一致性開銷，但是單個(gè)守護(hù)進(jìn)程（帶有一個(gè) RNIC）將導(dǎo)致有限的 RDMA 帶寬。在方法（c）中，使用哈希將計(jì)算節(jié)點(diǎn)分組，每個(gè)組對應(yīng)一個(gè)守護(hù)進(jìn)程，以避免單個(gè)守護(hù)進(jìn)程成為性能瓶頸。所有守護(hù)進(jìn)程都建立在相同的 CXL 內(nèi)存上，易于保證一致性。Rcmp 支持后兩種方法，方法（b）在小規(guī)模節(jié)點(diǎn)下默認(rèn)采用。

圖4. 機(jī)架間通信方法

圖5. 通信阻塞 與最新的內(nèi)存解耦合解決方案一樣，Rcmp 使用無鎖環(huán)形緩沖區(qū)實(shí)現(xiàn)高效的機(jī)架內(nèi)和機(jī)架間通信。

機(jī)架內(nèi)通信。引入守護(hù)進(jìn)程后，計(jì)算節(jié)點(diǎn)需要首先與守護(hù)進(jìn)程通信，確定數(shù)據(jù)存儲位置。簡單的解決方案是在 CXL 內(nèi)存中維護(hù)一個(gè)環(huán)形緩沖區(qū)，以管理計(jì)算節(jié)點(diǎn)與守護(hù)進(jìn)程之間的通信，這可能會導(dǎo)致混合架構(gòu)中的消息阻塞。如圖5所示，計(jì)算節(jié)點(diǎn)將訪問請求添加到環(huán)形緩沖區(qū)并等待守護(hù)進(jìn)程輪詢。在此示例中，CN1 首先發(fā)送 Msg1，然后 CN2 發(fā)送 Msg2。當(dāng)數(shù)據(jù)填滿時(shí)，當(dāng)前消息（Msg1）完成，下一個(gè)消息（Msg2）將被處理。如果 Msg1 是一個(gè)遠(yuǎn)程機(jī)架訪問請求，而 Msg2 是一個(gè)本地機(jī)架訪問請求，那么由于 RDMA 和 CXL 之間的性能差距，可能會先填滿 Msg2。由于每條消息的長度可變，守護(hù)進(jìn)程無法獲取 Msg2 的頭指針以跳過 Msg1 并首先處理 Msg2。Msg2 必須等待 Msg1 完成，導(dǎo)致消息阻塞。為避免通信阻塞，Rcmp 將本地和遠(yuǎn)程機(jī)架訪問解耦，并使用不同的環(huán)形緩沖區(qū)結(jié)構(gòu)，其中遠(yuǎn)程機(jī)架訪問采用雙層環(huán)形緩沖區(qū)。

機(jī)架間通信。不同機(jī)架中的守護(hù)進(jìn)程服務(wù)器通過具有單邊 RDMA 寫入/讀取的環(huán)形緩沖區(qū)進(jìn)行通信。

4.3 遠(yuǎn)程機(jī)架訪問優(yōu)化 由于非均勻訪問特性，遠(yuǎn)程機(jī)架訪問將是混合架構(gòu)的主要性能瓶頸。此外，由于直接I/O模型，對于任何粒度的遠(yuǎn)程機(jī)架數(shù)據(jù)訪問，都需要一次RDMA通信，導(dǎo)致高延遲，特別是對于頻繁的小數(shù)據(jù)訪問。Rcmp通過兩種方式優(yōu)化了這個(gè)問題：減少和加速遠(yuǎn)程機(jī)架訪問。

減少遠(yuǎn)程機(jī)架訪問。在真實(shí)數(shù)據(jù)中心中，訪問分布不均和熱點(diǎn)問題廣泛存在。因此，Rcmp提出了一種基于頁面的熱度識別和用戶級熱頁面交換方案，將頻繁訪問的頁面（熱頁面）遷移到本地機(jī)架，以減少遠(yuǎn)程機(jī)架訪問。 為了進(jìn)一步利用時(shí)間和空間局部性，Rcmp將遠(yuǎn)程機(jī)架的細(xì)粒度訪問緩存在CXL內(nèi)存中，并將寫請求批處理到遠(yuǎn)程機(jī)架。

加速RDMA通信。Rcmp提出了一種高性能的RDMA RPC（RRPC）框架，采用混合傳輸模式和其它優(yōu)化措施（例如，門鈴批處理），充分利用RDMA網(wǎng)絡(luò)的高帶寬。

05.?RCMP系統(tǒng)

在本章中，我們詳細(xì)描述了Rcmp系統(tǒng)和優(yōu)化策略。

5.1系統(tǒng)概述

Rcmp系統(tǒng)概述如圖6所示。Rcmp以機(jī)架為單位管理集群。機(jī)架內(nèi)所有 CN 和 MN 通過 CXL 鏈接相互連接，形成一個(gè)小的 CXL 內(nèi)存池。不同的機(jī)架通過 RDMA 連接起來，形成一個(gè)更大的內(nèi)存池。與基于 RDMA 的系統(tǒng)相比，Rcmp 可以實(shí)現(xiàn)更好的性能，與基于 CXL 的系統(tǒng)相比，具有更高的可擴(kuò)展性。MS 用于全局地址分配和元數(shù)據(jù)維護(hù)。在一個(gè)機(jī)架中，所有 CN 共享統(tǒng)一的 CXL 內(nèi)存。CN Lib 提供內(nèi)存池的 API。Daemon 服務(wù)器是機(jī)架的中央控制節(jié)點(diǎn)。它負(fù)責(zé)處理訪問請求，包括 CXL 請求（CXL 代理）和 RDMA 請求（消息管理器），交換熱頁（交換管理器），管理 slab 分配器，并維護(hù) CXL 內(nèi)存空間（資源管理器）。Daemon 運(yùn)行在每個(gè)機(jī)架內(nèi)的服務(wù)器上，與 CN 相同。此外，Rcmp 是一個(gè)用戶級架構(gòu)，避免了內(nèi)核和用戶空間之間的上下文切換開銷。

圖6. Rcmp系統(tǒng)概述

全局內(nèi)存管理。Rcmp 提供全局內(nèi)存地址管理，如圖7(a)所示。MS 以粗粒度頁面進(jìn)行內(nèi)存分配。全局地址 GAddr（page_id，page_offset）由 MS 分配的頁面 ID 和 CXL 內(nèi)存中的頁面偏移組成。Rcmp 使用兩個(gè)哈希表來存儲地址映射。具體來說，頁面目錄（在 MS 中）記錄了頁面 ID 到機(jī)架的映射，頁面表（在 Daemon 中）記錄了頁面 ID 到 CXL 內(nèi)存的映射。此外，為了支持細(xì)粒度數(shù)據(jù)訪問，Rcmp 使用 slab 分配器（一種對象緩存內(nèi)核內(nèi)存分配器）來處理細(xì)粒度內(nèi)存分配。頁面是2的冪的 slab 集合。

圖7. 全局內(nèi)存和地址管理 內(nèi)存空間包括 CXL 內(nèi)存和 CN 和 Daemon 的本地 DRAM，如圖7(b)所示。在一個(gè)機(jī)架中，每個(gè) CN 都有用于緩存本地機(jī)架頁面的元數(shù)據(jù)的小型本地 DRAM，包括頁面表和熱度信息。Daemon 的本地 DRAM（1）存儲本地機(jī)架頁面表和遠(yuǎn)程訪問的頁面熱度元數(shù)據(jù)，（2）緩存頁面目錄和遠(yuǎn)程機(jī)架的頁面表。CXL 內(nèi)存由兩部分組成：一個(gè)大型的共享一致內(nèi)存空間和每個(gè) CN 注冊的所有者內(nèi)存空間。所有者內(nèi)存用作遠(yuǎn)程機(jī)架的 CXL 緩存，用于寫緩沖和頁面緩存。

表4. Rcmp API

接口。如表4所示，Rcmp提供了常見的內(nèi)存池接口，包括打開/關(guān)閉、內(nèi)存分配/釋放、數(shù)據(jù)讀取/寫入以及鎖定/解鎖。打開操作根據(jù)用戶配置（ClientOptions）打開內(nèi)存池，在成功時(shí)返回內(nèi)存池上下文（PoolContext）指針，否則返回 nullptr。使用分配操作時(shí)，Daemon 在 CXL 內(nèi)存中為應(yīng)用程序查找一個(gè)空閑頁面，并更新頁面表。如果沒有空閑頁面，則根據(jù)接近原則在本地機(jī)架中分配頁面。如果機(jī)架中沒有空閑空間，則隨機(jī)在遠(yuǎn)程機(jī)架中分配頁面（例如，使用哈希函數(shù)）。讀取/寫入操作通過 CXL 在本地機(jī)架或 RDMA 在遠(yuǎn)程機(jī)架中讀取/寫入任意大小的數(shù)據(jù)。包括 RLock 和 WLock 的鎖定操作用于并發(fā)控制。鎖定地址必須首先進(jìn)行初始化。使用這些 API 來編程 Rcmp 的示例如圖8所示。

圖8. 使用Rcmp API的示例代碼

圖9. Rcmp的工作流程

工作流程。Rcmp 的訪問工作流程如圖9所示。當(dāng) CN 中的應(yīng)用程序使用讀取或?qū)懭氩僮髟L問內(nèi)存池時(shí)，請注意以下事項(xiàng)。首先，如果在本地 DRAM 中緩存的頁面表中找到頁面，則通過 Load/Store 操作直接訪問 CXL 內(nèi)存。其次，否則，從 MS 中找到頁面所在的機(jī)架，并且頁面目錄被緩存在 Daemon 的本地 DRAM 中。之后，就不需要聯(lián)系 MS，CN 直接與 Daemon 通信。第三，對于本地機(jī)架訪問，CN 通過搜索 Daemon 中的頁面表獲取數(shù)據(jù)位置（頁面偏移量）。然后，直接在 CXL 內(nèi)存中訪問。第四，對于遠(yuǎn)程機(jī)架訪問，Daemon 通過與遠(yuǎn)程機(jī)架中的 Daemon 通信獲取頁面偏移量并緩存頁面表。然后通過單邊 RDMA READ/WRITE 操作直接訪問遠(yuǎn)程機(jī)架中的數(shù)據(jù)。在這個(gè)過程中，遠(yuǎn)程機(jī)架中的 Daemon 通過 CXL 代理接收訪問請求并訪問 CXL 內(nèi)存。第五，如果在遠(yuǎn)程機(jī)架訪問時(shí)存在熱頁，則會觸發(fā)頁面交換機(jī)制。第六，如果存在 WLock 或 RLock，Rcmp 啟用寫入緩沖或頁面緩存以減少遠(yuǎn)程機(jī)架訪問。

5.2 機(jī)架內(nèi)通信 CN需要與 Daemon 通信以確定它們是本地機(jī)架訪問還是遠(yuǎn)程機(jī)架訪問，但是兩種情況的訪問延遲存在顯著差異。為防止通信阻塞，Rcmp 針對不同的訪問場景使用兩種環(huán)形緩沖區(qū)結(jié)構(gòu)，如圖10所示。

圖10. 機(jī)架內(nèi)通信機(jī)制

對于本地機(jī)架訪問，使用普通的環(huán)形緩沖區(qū)進(jìn)行通信。圖中的綠色緩沖區(qū)是一個(gè)示例。在這種情況下，由于所有訪問都是超低延遲（通過 CXL），即使在高沖突情況下也不會發(fā)生阻塞。此外，基于 Flock 的方法[36]，環(huán)形緩沖區(qū)（和 RDMA QP）在線程（一個(gè) CN）之間共享，以實(shí)現(xiàn)高并發(fā)性。

圖11. 熱頁交換

對于遠(yuǎn)程機(jī)架訪問，使用雙層環(huán)形緩沖區(qū)進(jìn)行高效和并發(fā)的通信，如圖10所示。第一個(gè)環(huán)形緩沖區(qū)（輪詢緩沖區(qū)）存儲消息元數(shù)據(jù)（例如，類型、大小）和一個(gè)指向第二個(gè)緩沖區(qū)（數(shù)據(jù)緩沖區(qū)）的指針 ptr，后者存儲消息數(shù)據(jù)。輪詢緩沖區(qū)中的數(shù)據(jù)長度固定，而數(shù)據(jù)緩沖區(qū)中的消息長度可變。當(dāng)數(shù)據(jù)緩沖區(qū)中的消息完成時(shí)，將請求添加到輪詢緩沖區(qū)。Daemon 輪詢輪詢緩沖區(qū)以處理當(dāng)前 ptr 指向的消息。例如，在圖10中，數(shù)據(jù)緩沖區(qū)中的后續(xù)消息 Msg2 首先填充，并且請求首先添加到輪詢緩沖區(qū)。因此，Msg2 將首先被處理，而不會發(fā)生阻塞。此外，不同的消息可以同時(shí)處理。在實(shí)現(xiàn)中，我們使用無鎖 KFIFO 隊(duì)列[50]作為輪詢緩沖區(qū)，數(shù)據(jù)緩沖區(qū)是普通的環(huán)形緩沖區(qū)。 5.3 熱頁識別與交換 為了減少遠(yuǎn)程機(jī)架訪問，Rcmp 設(shè)計(jì)了熱頁識別和交換策略。其目的是識別遠(yuǎn)程機(jī)架中經(jīng)常訪問的熱頁，并將它們遷移到本地機(jī)架。

熱頁識別。我們提出了一種過期策略來識別熱頁。具體來說，一個(gè)頁面的熱度由其訪問頻率和自上次訪問以來的時(shí)間段來衡量。我們維護(hù)三個(gè)變量，分別命名為 Curr、Curw 和 lastTime，用來表示頁面的讀訪問次數(shù)、寫訪問次數(shù)和最近一次訪問的時(shí)間。在訪問頁面并計(jì)算熱度時(shí)，我們首先得到 Δt，即當(dāng)前時(shí)間減去 lastTime。如果 Δt 大于有效生存期閾值 Tl，則將頁面定義為“過期”，并將 Curr、Curw 清零。頁面的熱度等于 α × (Curr + Curw) + 1，其中 α 是指數(shù)衰減因子，α = e^-λΔt，λ 是一個(gè)“衰減”常數(shù)。然后，根據(jù)訪問類型，Curr 或 Curw 加 1。如果熱度大于閾值 Hp，則頁面為“熱頁”。此外，如果熱頁的 (Curr/Curw) 大于閾值 Rrw，則頁面為“讀熱”。所有閾值都是可配置的，并具有默認(rèn)值。在一個(gè)機(jī)架中，所有 CN（本地 DRAM）維護(hù)本地機(jī)架頁面的熱度值（或熱度元數(shù)據(jù)），而遠(yuǎn)程機(jī)架頁面的熱度元數(shù)據(jù)存儲在 Daemon 中。由于每個(gè)頁面維護(hù)三個(gè)變量，約為 32 字節(jié)，內(nèi)存開銷很小。更新頁面的熱度元數(shù)據(jù)的時(shí)間復(fù)雜度也很低，僅為 O(1)。

熱頁交換與緩存。Rcmp 提出了一種用戶級別的交換機(jī)制，與基于頁面的系統(tǒng)的交換機(jī)制（如 LegoOS、Infiniswap）不同，后者依賴于主機(jī)的內(nèi)核交換守護(hù)程序（kswapd）[3, 21, 22, 44]。以 R1 機(jī)架中希望交換 R2 機(jī)架中熱頁的 CN 為例，交換過程如下。1 R1（Daemon）的交換請求發(fā)送到 MS，并添加到 FIFO 隊(duì)列中，該隊(duì)列用于避免重復(fù)請求同一頁面導(dǎo)致系統(tǒng)被淹沒。2 R1 選擇空閑頁面作為要交換的頁面。如果沒有空閑空間，則收集所有 CN 的熱度元數(shù)據(jù)，并選擇熱度最低的頁面作為要交換的頁面。如果要交換的頁面仍然是“熱頁”（例如，掃描工作負(fù)載），則停止交換過程，轉(zhuǎn)向 6。3 R2 求和頁面的熱度（與 R1 交換的頁面）在所有 CN 中的熱度，并將結(jié)果與 R1 的熱度進(jìn)行比較。如果 R2 的熱度更高，則拒絕交換過程，轉(zhuǎn)向 6，但如果對于 R1，該頁面是“讀熱”的，則該頁面將被緩存在 R1 的 CXL 存儲器中。頁面緩存是只讀的，在頁面需要寫入時(shí)將被刪除（見第 5.4 節(jié)）。這種基于比較的方法避免了頁面頻繁遷移（頁面乒乓效應(yīng)）。此外，在讀密集型工作負(fù)載下，通過緩存“讀熱”數(shù)據(jù)可以提高性能。4 R2 禁用有關(guān)頁面的熱度元數(shù)據(jù)，并更新所有 CN 的頁面表。5 根據(jù)兩個(gè)單向 RDMA 操作交換熱頁。6 更新頁面表，R1 的請求出隊(duì)。

5.4 CXL緩存和同步機(jī)制 為了減少大規(guī)模細(xì)粒度工作負(fù)載下頻繁的遠(yuǎn)程訪問，Rcmp提出了一種簡單高效的緩存和同步機(jī)制，基于Lock/UnLock操作。其主要思想是通過緩存線粒度將鎖與數(shù)據(jù)耦合在一起，即相同緩存線中的數(shù)據(jù)共享同一把鎖[9]。Rcmp為每個(gè)CN在CXL內(nèi)存中設(shè)計(jì)了寫入緩沖區(qū)和頁面緩存，并通過同步機(jī)制實(shí)現(xiàn)了機(jī)架間的一致性。機(jī)架內(nèi)的一致性可以通過CXL來保證，無需額外的策略。

CXL寫入緩沖區(qū)。通過WLock操作，請求節(jié)點(diǎn)（CN）成為所有者節(jié)點(diǎn)（其它節(jié)點(diǎn)無法修改）。在這種情況下，CN可以將遠(yuǎn)程機(jī)架的細(xì)粒度寫入請求（默認(rèn)情況下小于256B）緩存在CXL寫入緩沖區(qū)中。當(dāng)緩沖區(qū)達(dá)到一定大小或WLock被解鎖時(shí)，Rcmp使用后臺線程異步批處理寫入對應(yīng)的遠(yuǎn)程機(jī)架。我們目前的實(shí)現(xiàn)使用兩個(gè)緩沖區(qū)結(jié)構(gòu)，當(dāng)一個(gè)緩沖區(qū)已滿時(shí)，所有寫入請求會轉(zhuǎn)到新的緩沖區(qū)。緩沖區(qū)結(jié)構(gòu)默認(rèn)為高并發(fā)SkipList，類似于LSM-KV存儲中的內(nèi)存表結(jié)構(gòu)[12]。

CXL頁面緩存。類似地，當(dāng)使用RLock操作時(shí)，CN變?yōu)楣蚕砉?jié)點(diǎn)。頁面可以緩存在CXL頁面緩存中，在頁面交換過程中的第3步。當(dāng)頁面將要被寫入或RLock被解鎖時(shí)，CN將使頁面緩存無效。
5.5 RRPC框架 與傳統(tǒng)的RDMA和RPC框架相比，RRPC采用了一種混合方法，可以根據(jù)不同的數(shù)據(jù)模式自適應(yīng)地選擇RPC和單邊RDMA通信。RRPC受圖3中的測試結(jié)果啟發(fā)，使用512B作為閾值動態(tài)選擇通信模式。其主要思想是有效地利用RDMA的高帶寬特性來分?jǐn)偼ㄐ叛舆t。如圖12所示，RRPC包括三種通信模式。

圖12. RRPC中的不同通信模式 純RPC模式用于傳輸數(shù)據(jù)量小于512B的通信，包括事務(wù)中的鎖定、數(shù)據(jù)索引查詢和內(nèi)存分配等場景。 RPC和單邊RDMA模式適用于非結(jié)構(gòu)化大數(shù)據(jù)（超過512B）和未知數(shù)據(jù)大小的場景，如對象存儲場景。在這種情況下，客戶端在請求服務(wù)器之前很難知道要訪問的對象的大小。因此，需要先通過RPC獲取遠(yuǎn)程地址，然后在本地分配指定大小的空間，并最終通過RDMA單邊讀操作進(jìn)行遠(yuǎn)程獲取。 RPC零拷貝模式適用于結(jié)構(gòu)化大數(shù)據(jù)（超過512B）且大小固定的場景，例如SQL場景。由于數(shù)據(jù)具有固定的大小，通信模式在發(fā)送RPC請求時(shí)可以攜帶本地空間的地址，并且數(shù)據(jù)可以直接通過RDMA單邊寫操作寫入。 對于后兩種模式，一旦通過RPC獲取了頁面地址，Rcmp將對其進(jìn)行緩存，并且在后續(xù)訪問中只使用單邊RDMA讀/寫。此外，RRPC采用QP共享、門鈴批處理等方法來優(yōu)化RDMA通信，借鑒了其它工作的優(yōu)點(diǎn)。

06.?評估

在本章中，我們使用不同的基準(zhǔn)測試評估了Rcmp的性能。首先介紹了Rcmp的實(shí)現(xiàn)和實(shí)驗(yàn)設(shè)置（第6.1節(jié)和第6.2節(jié)）。接下來，我們使用微基準(zhǔn)測試將Rcmp與其它三個(gè)遠(yuǎn)程內(nèi)存系統(tǒng)進(jìn)行比較（第6.3節(jié)）。然后，我們運(yùn)行了一個(gè)使用YCSB基準(zhǔn)測試的鍵值存儲，以展示Rcmp的性能優(yōu)勢（第6.4節(jié)）。最后，我們評估了Rcmp中關(guān)鍵技術(shù)的影響（第6.5節(jié)）。

6.1 實(shí)現(xiàn) Rcmp是一個(gè)用戶級系統(tǒng)，沒有內(nèi)核空間的修改，實(shí)現(xiàn)了6483行C++代碼。在Rcmp中，頁面默認(rèn)為2 MB，因?yàn)樗谠獢?shù)據(jù)大小和延遲之間取得了良好的平衡；每個(gè)寫緩沖區(qū)為64 MB，頁面緩存為LRU緩存，包含50頁；閾值Tl默認(rèn)為100秒，Hp為4，λ為0.04，Rrw為0.9。這些閾值根據(jù)應(yīng)用場景進(jìn)行調(diào)整。RRPC框架是基于eRPC實(shí)現(xiàn)的。 雖然現(xiàn)在可以購買支持CXL的FPGA原型，但我們?nèi)匀贿x擇基于NUMA的仿真來實(shí)現(xiàn)CXL內(nèi)存，原因有兩個(gè)。首先，在英特爾的測量中，基于FPGA的原型具有更高的延遲，超過250 ns。正如CXL總裁Siamak Tavallaei所介紹的那樣，“這些早期的CXL概念驗(yàn)證和產(chǎn)品尚未針對延遲進(jìn)行優(yōu)化。隨著時(shí)間的推移，CXL內(nèi)存的訪問延遲將得到顯著改善?！逼浯危祟愃频脑L問延遲外，NUMA架構(gòu)是高速緩存一致性的，使用Load/Store語義作為CXL。

6.2 實(shí)驗(yàn)設(shè)置 所有實(shí)驗(yàn)均在五臺服務(wù)器上進(jìn)行，每臺服務(wù)器配備兩個(gè)套裝的Intel Xeon Gold 5218R CPU @ 2.10 GHz，128 GB DRAM，以及一個(gè)100-Gbps Mellanox ConnectX-5 RNIC。操作系統(tǒng)為Ubuntu 20.04，內(nèi)核版本為Linux 5.4.0-144-generic。NUMA節(jié)點(diǎn)0和節(jié)點(diǎn)1之間的互連延遲為138.5 ns和141.1 ns，節(jié)點(diǎn)內(nèi)訪問延遲分別為93 ns和89.7 ns。 Rcmp與其它四種最先進(jìn)的遠(yuǎn)程內(nèi)存系統(tǒng)進(jìn)行了比較：（1）Fastswap[3]，一個(gè)基于頁面的系統(tǒng)；（2）FaRM[17]，一個(gè)基于對象的系統(tǒng)；（3）GAM[9]，一個(gè)通過RDMA提供緩存一致性協(xié)議的分布式內(nèi)存系統(tǒng)；以及（4）CXL-over-Ethernet，一個(gè)基于CXL的內(nèi)存解耦合系統(tǒng)，使用以太網(wǎng)（詳情見第7章）。我們使用開源代碼運(yùn)行Fastswap和GAM。由于FaRM不是公開的，我們使用Cai等人的工作中的代碼[9]。請注意，F(xiàn)aRM和GAM實(shí)際上不是真正的“分離式”架構(gòu)；它們的CN具有與遠(yuǎn)程內(nèi)存相同大小的本地內(nèi)存。我們修改了一些配置（減少本地內(nèi)存）以將它們移植到分離的架構(gòu)中。由于缺乏FPGA設(shè)備和CXL-over-Ethernet的未發(fā)布源代碼，我們基于Rcmp的代碼實(shí)現(xiàn)了CXL-over-Ethernet原型。為了公平起見，RDMA網(wǎng)絡(luò)也用于CXL-over-Ethernet。

圖13. 設(shè)想的原型和模擬環(huán)境

系統(tǒng)部署和模擬環(huán)境。圖13(a)顯示了Rcmp的構(gòu)想架構(gòu)。在一個(gè)機(jī)架中，低延遲的CXL用于連接CN和MN以形成一個(gè)小內(nèi)存池；RDMA用于連接機(jī)架（與支持RDMA的ToR交換機(jī)的互連）。CXL鏈接速度為90至150 ns；RDMA網(wǎng)絡(luò)延遲為1.5至3微秒。我們的測試環(huán)境如圖13(b)所示。由于設(shè)備有限，我們使用一臺服務(wù)器模擬一個(gè)機(jī)架，包括一個(gè)小型計(jì)算池和內(nèi)存池（或CXL內(nèi)存）。對于Rcmp和CXL-over-Ethernet，計(jì)算池在一個(gè)CPU插槽上運(yùn)行，一個(gè)無CPU的MN作為CXL內(nèi)存。在Rcmp的計(jì)算池中，不同進(jìn)程運(yùn)行不同的CN客戶端，一個(gè)進(jìn)程運(yùn)行Daemon。對于其它系統(tǒng)，內(nèi)存池通過RDMA連接到計(jì)算池。此外，機(jī)架中的內(nèi)存池或CXL內(nèi)存具有約100 GB的DRAM，計(jì)算池的本地DRAM為1 GB。我們使用微基準(zhǔn)測試評估不同系統(tǒng)的基本讀/寫性能，并使用YCSB基準(zhǔn)測試[15]評估它們在不同工作負(fù)載下的性能，如表5所示。

表5. YCSB工作負(fù)載

6.3 微基準(zhǔn)測試結(jié)果 我們首先通過運(yùn)行帶有隨機(jī)讀寫操作的微基準(zhǔn)測試來評估這些系統(tǒng)的整體性能和可擴(kuò)展性。數(shù)據(jù)大小默認(rèn)為64B，并且每次讀寫操作使用100M數(shù)據(jù)項(xiàng)。

圖14. 訪問延遲

整體性能。如圖14所示，在兩個(gè)機(jī)架的環(huán)境下，我們運(yùn)行微基準(zhǔn)測試10次，使用不同的數(shù)據(jù)大小，并比較平均延遲。每個(gè)機(jī)架都預(yù)先分配了相同數(shù)量的內(nèi)存頁面。 結(jié)果顯示，Rcmp具有更低且更穩(wěn)定的寫入/讀取延遲（<3.5μs和<3μs）。具體來說，與其它系統(tǒng)相比，寫入延遲降低了2.3到8.9倍，讀取延遲降低了2.7到8.1倍。這是通過Rcmp對CXL的有效利用實(shí)現(xiàn)的，其中包括了有效的通信和熱頁面交換等設(shè)計(jì)，以最小化系統(tǒng)延遲。Fastswap的訪問延遲超過了12μs，比Rcmp高出約5.2倍。當(dāng)所訪問的數(shù)據(jù)不在本地DRAM緩存中時(shí)，F(xiàn)astswap會基于高成本的頁面故障從遠(yuǎn)程內(nèi)存池獲取頁面，導(dǎo)致了更高的開銷。

FaRM具有較低的讀/寫延遲，約為8μs，這是由于其基于對象的數(shù)據(jù)管理和高效的消息原語來改善RDMA通信。GAM也是一種基于對象的系統(tǒng)，當(dāng)數(shù)據(jù)大小小于512B時(shí)性能表現(xiàn)良好（約5μs），但當(dāng)數(shù)據(jù)較大時(shí)，延遲會急劇增加。這是因?yàn)镚AM使用512B作為默認(rèn)的緩存行大小，當(dāng)數(shù)據(jù)跨越多個(gè)緩存行時(shí)，GAM需要同步地在所有緩存行上維護(hù)一致性狀態(tài)，導(dǎo)致性能下降。此外，寫操作在GAM中是異步的且流水線化的，具有較低的寫延遲（見圖14(a)）。CXL-over-Ethernet通過CXL也實(shí)現(xiàn)了低的讀寫延遲（6-8μs）。然而，CXL-over-Ethernet在計(jì)算池中部署CXL，并為內(nèi)存池采用緩存策略，沒有充分利用CXL低延遲的優(yōu)勢。此外，CXL-over-Ethernet并未針對網(wǎng)絡(luò)進(jìn)行優(yōu)化，這是混合架構(gòu)的主要性能瓶頸。

可擴(kuò)展性。我們通過改變不同的客戶端和機(jī)架來測試不同系統(tǒng)的可擴(kuò)展性。每個(gè)客戶端都運(yùn)行一個(gè)微基準(zhǔn)測試。我們有五臺服務(wù)器，最多可以建立五個(gè)機(jī)架。

圖15. 不同客戶端下的總吞吐量 首先，我們在雙機(jī)架環(huán)境中比較了多個(gè)客戶端同時(shí)讀/寫的吞吐量。如圖15所示，當(dāng)客戶端少于16個(gè)時(shí)，Rcmp的吞吐量與客戶端數(shù)量大致呈線性關(guān)系。然而，當(dāng)客戶端數(shù)量增多時(shí)，由于只有一個(gè)守護(hù)進(jìn)程，可擴(kuò)展性受到限制。因此，對于規(guī)模更大的節(jié)點(diǎn)，Rcmp將采用多個(gè)守護(hù)進(jìn)程服務(wù)器（參見第4.2節(jié)）。由于高效的頁面錯(cuò)誤驅(qū)動遠(yuǎn)程內(nèi)存訪問，F(xiàn)astswap隨著客戶端的增加幾乎呈線性增長。FaRM在讀操作方面尤其具有良好的可擴(kuò)展性，這要?dú)w功于高效的通信原語。相比之下，GAM僅在四個(gè)線程內(nèi)表現(xiàn)出線性可擴(kuò)展性。當(dāng)涉及更多客戶端時(shí)，GAM的性能改善幅度較小，甚至可能是負(fù)的，這是由于其用戶級庫的軟件開銷。為了確保一致性，GAM必須獲取鎖來檢查每個(gè)內(nèi)存訪問的訪問權(quán)限，在密集訪問場景中這會帶來很高的開銷。在CXL-over-Ethernet中，除了8個(gè)線程之外，其它線程在通過CXL代理訪問內(nèi)存池之前都需要進(jìn)行通信，這成為性能瓶頸。

圖16. 不同機(jī)架下的每機(jī)架吞吐量 其次，我們增加了機(jī)架數(shù)量，并在每個(gè)機(jī)架上運(yùn)行了八個(gè)客戶端。每個(gè)機(jī)架的訪問數(shù)據(jù)均勻分布在整個(gè)內(nèi)存池中。如圖16所示，F(xiàn)astswap的吞吐量不受機(jī)架數(shù)量的影響，并具有出色的可擴(kuò)展性。Rcmp和FaRM由于不同機(jī)架之間的競爭而略有性能損失。在Rcmp中，還存在熱頁交換的競爭，但通過熱頁識別機(jī)制得到緩解。GAM的緩存一致性開銷在多機(jī)架環(huán)境中變得更加明顯，導(dǎo)致性能嚴(yán)重下降。對于CXL-over-Ethernet，計(jì)算池中的代理限制了可擴(kuò)展性。 總之，Rcmp通過幾項(xiàng)創(chuàng)新設(shè)計(jì)有效地利用了CXL來減少訪問延遲并提高可擴(kuò)展性，而其它系統(tǒng)則面臨著較高的延遲或可擴(kuò)展性較差的問題。

6.4 鍵值存儲和YCSB工作負(fù)載 我們在這些系統(tǒng)上運(yùn)行了一個(gè)通用的鍵值存儲接口，該接口在內(nèi)部實(shí)現(xiàn)為哈希表。接著，我們運(yùn)行了廣泛使用的YCSB基準(zhǔn)測試[15]（如表5所示的六種工作負(fù)載）來評估性能。由于哈希表不支持范圍查詢，因此不執(zhí)行YCSB E工作負(fù)載。所有實(shí)驗(yàn)均在雙機(jī)架環(huán)境中運(yùn)行。我們預(yù)先加載了100M個(gè)鍵值對，每個(gè)大小為64B，然后在均勻分布和Zipfian分布（默認(rèn)偏斜度為0.99）下執(zhí)行不同的工作負(fù)載。圖17顯示了不同系統(tǒng)的吞吐量，所有數(shù)據(jù)均標(biāo)準(zhǔn)化為Fastswap?；谶@一結(jié)果，可以得出以下結(jié)論。

圖17. YCSB工作負(fù)載的歸一化吞吐量 首先，通過有效地利用CXL，Rcmp在所有工作負(fù)載上的性能均比基于RDMA的系統(tǒng)提高2到4倍。具體而言，對于讀密集型工作負(fù)載（YCSB B、C、D），Rcmp的性能比Fastswap提高了約3倍，避免了頁面錯(cuò)誤開銷，并通過熱頁交換減少了機(jī)架間的數(shù)據(jù)移動。此外，Rcmp設(shè)計(jì)了高效的通信機(jī)制和RRPC框架以實(shí)現(xiàn)最佳性能。

FaRM、GAM和CXL-over-Ethernet的性能也更好，比Fastswap提高了約1.5倍。這是因?yàn)镕aRM只需一個(gè)單邊無鎖讀操作即可進(jìn)行遠(yuǎn)程訪問。GAM或CXL-over-Ethernet在本地內(nèi)存或CXL內(nèi)存中提供統(tǒng)一的緩存策略。在內(nèi)存解耦合架構(gòu)下，緩存的好處受到本地DRAM的限制。對于寫密集型工作負(fù)載（YCSB A和F），Rcmp的吞吐量提高了1.5倍。 其次，Rcmp在Zipfian工作負(fù)載中的性能提升更加顯著，吞吐量提高了最多3.8倍。

由于熱頁在Zipfian工作負(fù)載下經(jīng)常被訪問，Rcmp通過將熱頁遷移到本地機(jī)架，大大減少了慢速遠(yuǎn)程機(jī)架訪問。在Zipfian工作負(fù)載下，GAM和CXL-over-Ethernet也有顯著的性能改進(jìn)，這是由于高緩存命中率。 總之，通過有效地利用CXL和其它優(yōu)化措施，Rcmp在性能上優(yōu)于其它系統(tǒng)。在內(nèi)存解耦合架構(gòu)中，其它系統(tǒng)存在明顯的限制，大多數(shù)數(shù)據(jù)是通過訪問遠(yuǎn)程內(nèi)存池獲取的。 例如，基于內(nèi)核的、以頁面為粒度的Fastswap具有高成本的中斷開銷。GAM的緩存策略在稀缺的本地內(nèi)存中性能提升有限。此外，F(xiàn)aRM的一些操作依賴于雙邊協(xié)作，這與由于內(nèi)存池的近零計(jì)算能力而與這種分離式架構(gòu)不兼容。

6.5 關(guān)鍵技術(shù)的影響 本節(jié)重點(diǎn)討論四種策略對Rcmp性能的影響，包括通信機(jī)制、交換和緩存策略以及RRPC。這些策略旨在減輕性能不匹配問題（介于RDMA和CXL之間）并最大化CXL的性能優(yōu)勢。

圖18. 技術(shù)對性能的貢獻(xiàn) 我們首先逐個(gè)應(yīng)用Rcmp的關(guān)鍵技術(shù)，在雙機(jī)架環(huán)境下的微基準(zhǔn)測試結(jié)果如圖18所示?；鶞?zhǔn)表示Rcmp的基本版本，包括單層環(huán)形緩沖區(qū)、eRPC等。+RB表示采用雙層環(huán)形緩沖區(qū)；+Swap和+WB表示進(jìn)一步應(yīng)用熱頁交換和CXL寫緩沖區(qū)；+RRPC表示采用RRPC框架，并展示了Rcmp的最終性能。Rcmp-only-CXL表示所有讀/寫操作在機(jī)架內(nèi)執(zhí)行，不涉及RDMA網(wǎng)絡(luò)。從理論上講，純CXL解決方案是Rcmp性能的上限，但只能在機(jī)架內(nèi)部署。結(jié)果顯示，這些技術(shù)降低了Rcmp與Rcmp-only-CXL之間的性能差距，但Rcmp在尾部延遲和讀吞吐量方面仍有改進(jìn)空間。其中，雙層環(huán)形緩沖區(qū)減少了延遲，尤其是尾部延遲。交換策略極大地降低了延遲，提高了吞吐量，這在讀操作中更為明顯。寫緩沖區(qū)和RRPC顯著提高了吞吐量，寫緩沖區(qū)主要影響寫操作。 然后，我們詳細(xì)分析了每種技術(shù)的好處。默認(rèn)情況下，所有實(shí)驗(yàn)均在雙機(jī)架環(huán)境中運(yùn)行。

圖19. 環(huán)形緩沖區(qū)

圖20. 熱頁交換

圖21. 寫入緩沖區(qū)

圖22. RRPC框架

機(jī)架內(nèi)通信。如圖19所示，我們比較了兩種策略在微基準(zhǔn)測試下的延遲（p50、p99、p999）：（1）使用單個(gè)環(huán)形緩沖區(qū)（基準(zhǔn)線）和（2）使用兩個(gè)環(huán)形緩沖區(qū)進(jìn)行不同訪問模式（Rcmp）。結(jié)果顯示，Rcmp將第50、99和999百分位延遲分別降低了最多21.7%、30.9%和51.5%。由于本地和遠(yuǎn)程機(jī)架訪問之間的延遲差距，單一通信緩沖區(qū)可能導(dǎo)致阻塞問題，觸發(fā)更長的尾部延遲。Rcmp通過高效的通信機(jī)制解決了這個(gè)問題。

熱頁交換。我們在不同分布（均勻、Zipfian）下運(yùn)行微基準(zhǔn)測試，以評估熱頁交換的效果。結(jié)果如圖20所示，可以得出以下結(jié)論。首先，熱頁交換策略可以顯著提高性能，特別是對于傾斜的工作負(fù)載。例如，交換策略（Hp=3）可以使均勻工作負(fù)載的吞吐量提高5%，在Zipfian工作負(fù)載下提高35%。其次，頻繁的頁面交換會導(dǎo)致性能下降。當(dāng)熱度閾值設(shè)置得很低時(shí)（例如Hp=1），吞吐量會暴跌，因?yàn)楫?dāng)閾值很低時(shí)，每次遠(yuǎn)程訪問可能會觸發(fā)一次頁面交換（類似于基于頁面的系統(tǒng)），導(dǎo)致高額外開銷。

寫緩沖區(qū)。假設(shè)使用WLock操作的場景，我們通過在不同數(shù)據(jù)大小下運(yùn)行微基準(zhǔn)測試來評估使用寫緩沖區(qū)（Rcmp）和不使用緩沖區(qū)（基準(zhǔn)線）的吞吐量。如圖21所示，Rcmp在所有數(shù)據(jù)大小下的吞吐量均比基準(zhǔn)線高出最多1.6倍。數(shù)據(jù)被緩存在寫緩沖區(qū)中，并通過后臺線程異步批處理到遠(yuǎn)程機(jī)架。因此，Rcmp將寫操作從關(guān)鍵執(zhí)行路徑中移除，并減少了對遠(yuǎn)程機(jī)架的訪問，增強(qiáng)了寫性能。然而，當(dāng)數(shù)據(jù)大于256B時(shí)，性能提升不明顯，并且后臺線程會導(dǎo)致更多的CPU開銷。因此，當(dāng)數(shù)據(jù)大于256B時(shí)，Rcmp不使用寫緩沖區(qū)。

RRPC框架。我們將RRPC與FaRM的RPC [17]、eRPC [24]框架和混合模式（eRPC + 單邊RDMA動詞）在不同傳輸數(shù)據(jù)大小下進(jìn)行比較。如圖22所示，當(dāng)傳輸數(shù)據(jù)較大時(shí)，RRPC的吞吐量比eRPC + 單邊RDMA動詞高出1.33到1.89倍，比eRPC高出1.5到2倍。eRPC在數(shù)據(jù)小于968B時(shí)表現(xiàn)良好，但當(dāng)數(shù)據(jù)較大時(shí)，eRPC性能下降。這是因?yàn)閑RPC基于UD（不可靠數(shù)據(jù)報(bào)）模式，每個(gè)消息有一個(gè)MTU（最大傳輸單元）大小，默認(rèn)為1KB，當(dāng)數(shù)據(jù)大于MTU大小時(shí)，它將被分成多個(gè)數(shù)據(jù)包，導(dǎo)致性能下降。RRPC只會在數(shù)據(jù)小于512B時(shí)選擇eRPC方法，并在數(shù)據(jù)較大時(shí)選擇混合模式。此外，RRPC采用了幾種策略來提高RDMA通信性能。

6.6討論 支持去中心化。中心化設(shè)計(jì)使得MS容易成為性能瓶頸，Rcmp通過利用CN本地DRAM來減輕這一問題。Rcmp試圖實(shí)現(xiàn)一種具有一致性哈希的去中心化架構(gòu)，并使用Zookeeper可靠地維護(hù)集群成員關(guān)系，類似于FaRM。 支持緩存I/O。Rcmp采用無緩存訪問模式，避免了跨機(jī)架維護(hù)一致性的開銷。通過去中心化架構(gòu)，Rcmp可以在CXL內(nèi)存中為遠(yuǎn)程機(jī)架設(shè)計(jì)緩存結(jié)構(gòu)，并使用Zookeeper在機(jī)架之間維護(hù)緩存一致性。

透明性。盡管Rcmp提供了非常簡單的API和標(biāo)準(zhǔn)數(shù)據(jù)結(jié)構(gòu)的內(nèi)置實(shí)現(xiàn)（例如哈希表），但仍然有許多場景希望將傳統(tǒng)應(yīng)用遷移到Rcmp而無需修改其源代碼。參考Gengar [18]，我們將Rcmp與FUSE [1]集成，實(shí)現(xiàn)了一個(gè)簡單的分布式文件系統(tǒng)，可以用于大多數(shù)應(yīng)用而無需修改源代碼。使用說明可以在Rcmp的源代碼中找到，網(wǎng)址為https://github.com/PDS-Lab/Rcmp。

07.?相關(guān)工作

7.1 基于 RDMA 的遠(yuǎn)程內(nèi)存 基于頁面的系統(tǒng)。

Infiniswap [22] 是一種基于頁面的遠(yuǎn)程內(nèi)存系統(tǒng)，使用 RDMA 網(wǎng)絡(luò)，執(zhí)行分散式頁面分配和回收，利用單邊 RDMA 操作。Infiniswap 使用內(nèi)核空間的塊設(shè)備作為交換空間，在用戶空間中使用守護(hù)進(jìn)程管理可訪問的遠(yuǎn)程內(nèi)存。類似的基于頁面的系統(tǒng)包括 LegoOS [44]，這是一個(gè)新型資源分離式操作系統(tǒng)，提供全局虛擬內(nèi)存空間；Clover [51]，一個(gè)基于 RDMA 的分離式持久性內(nèi)存（pDPM）系統(tǒng)，將元數(shù)據(jù)/控制平面與數(shù)據(jù)平面分離；Fastswap [3]，一種通過遠(yuǎn)程感知的遠(yuǎn)程內(nèi)存快速交換系統(tǒng)，通過遠(yuǎn)程感知的集群調(diào)度程序等。然而，這些基于頁面的系統(tǒng)存在 I/O 放大問題，因?yàn)椴僮髁６容^粗，需要處理頁面錯(cuò)誤和上下文切換等額外開銷。

基于對象的系統(tǒng)?；趯ο蟮膬?nèi)存解耦合系統(tǒng)設(shè)計(jì)自己的對象接口（如鍵值存儲），直接參與 RDMA 數(shù)據(jù)傳輸。FaRM [17] 是一種基于 RDMA 的基于對象的遠(yuǎn)程內(nèi)存系統(tǒng)，將集群中所有服務(wù)器的內(nèi)存公開為共享地址空間，并提供高效的 API 簡化遠(yuǎn)程內(nèi)存的使用。AIFM [41] 是一種應(yīng)用集成的遠(yuǎn)程內(nèi)存系統(tǒng)，提供便捷的 API，采用高性能的運(yùn)行時(shí)設(shè)計(jì)以最小化對象訪問的開銷。Xstore [57] 采用學(xué)習(xí)索引構(gòu)建 RDMA 基礎(chǔ)的鍵值存儲中的遠(yuǎn)程內(nèi)存緩存。然而，這些系統(tǒng)并非完全“解耦合”，因?yàn)槊總€(gè) CN 包含與遠(yuǎn)程內(nèi)存相同大小的本地內(nèi)存。FUSEE 是一個(gè)完全內(nèi)存解耦合的鍵值存儲，基于 RACE 哈希索引 [67] 實(shí)現(xiàn)了對元數(shù)據(jù)管理的內(nèi)存解耦合，這是一種單邊 RDMA 感知的可擴(kuò)展哈希。Gengar [18] 是一個(gè)基于對象的混合內(nèi)存池系統(tǒng)，提供全局內(nèi)存空間（包括遠(yuǎn)程 NVM 和 DRAM）通過 RDMA。

通信優(yōu)化。大多數(shù)基于 RDMA 的系統(tǒng)提出了優(yōu)化策略，提高 RDMA 通信效率。FaRM 提出了基于無鎖環(huán)形緩沖區(qū)的消息傳遞原語，最小化遠(yuǎn)程內(nèi)存的通信開銷。此外，F(xiàn)aRM 通過共享 QP 減少了 RNIC 的緩存未命中。Clover 通過使用巨大內(nèi)存頁（HugePage）注冊內(nèi)存區(qū)域提高 RDMA 的可擴(kuò)展性。Xstore 使用門鈴批處理減少多個(gè) RDMA 讀/寫操作的網(wǎng)絡(luò)延遲。FaSST [26] 提出了一種快速的 RPC 框架，使用雙邊不可靠的 RDMA 而不是單邊動詞，特別適用于小消息。然而，雙邊動詞不適用于分離式架構(gòu)，并且 FaSST 對大消息不高效。許多遠(yuǎn)程系統(tǒng)采用 eRPC [24]，這是一個(gè)通用的 RPC 庫，提供可比較的性能，沒有 RDMA 原語。但我們觀察到，僅 RPC 對于內(nèi)存解耦合系統(tǒng)并不是最優(yōu)的。

7.2 支持緩存一致性 GAM [9] 是一個(gè)利用 RDMA 提供緩存一致性內(nèi)存的分布式內(nèi)存系統(tǒng)。GAM 通過基于目錄的緩存一致性協(xié)議在本地和遠(yuǎn)程內(nèi)存之間維護(hù)一致性。然而，這種方法具有很高的維護(hù)開銷。新的互連協(xié)議，如 CXL [45] 或 CCIX [6]，原生支持緩存一致性，并且與 RDMA 相比具有更低的延遲。一些研究人員嘗試使用這些協(xié)議重新設(shè)計(jì)基于 RDMA 的內(nèi)存解耦合。Kona [10] 使用緩存一致性而不是虛擬內(nèi)存來透明跟蹤應(yīng)用程序的內(nèi)存訪問，從而減少基于頁面的系統(tǒng)中的讀/寫放大。Rambda [61] 是一個(gè)使用緩存一致性加速器連接到類似 CXL 的緩存一致性內(nèi)存的 RDMA 驅(qū)動加速框架，并采用 cpoll 機(jī)制來減少輪詢開銷。

7.3 基于 CXL 的內(nèi)存解耦合 DirectCXL [21] 是一種基于 CXL 的內(nèi)存解耦合，實(shí)現(xiàn)了通過 CXL 協(xié)議直接訪問遠(yuǎn)程內(nèi)存。DirectCXL 的延遲比基于 RDMA 的內(nèi)存解耦合低 6.2 倍。Pond [30] 是云平臺的內(nèi)存池系統(tǒng)，基于 CXL 顯著降低了 DRAM 成本。然而，這些系統(tǒng)沒有考慮 CXL 的距離限制。CXL-over-Ethernet [56] 是一種新型基于 FPGA 的內(nèi)存解耦合，通過 Ethernet 忽略了 CXL 的限制，但沒有充分利用 CXL 的性能優(yōu)勢。

08.?結(jié)論與未來工作

在這項(xiàng)研究中，我們開發(fā)了 Rcmp，一個(gè)低延遲、高可擴(kuò)展的內(nèi)存池系統(tǒng)，首次將 RDMA 和 CXL 結(jié)合起來實(shí)現(xiàn)內(nèi)存解耦合。Rcmp 在機(jī)架內(nèi)構(gòu)建了一個(gè)基于 CXL 的內(nèi)存池，并使用 RDMA 連接機(jī)架，形成一個(gè)全局內(nèi)存池。Rcmp 采用了多種技術(shù)來解決 RDMA 和 CXL 之間不匹配的挑戰(zhàn)。Rcmp 提出了一種全局內(nèi)存和地址管理方式，以支持以緩存行粒度訪問。此外，Rcmp 使用不同的緩沖結(jié)構(gòu)來處理機(jī)架內(nèi)和機(jī)架間的通信，避免了阻塞問題。為了減少對遠(yuǎn)程機(jī)架的訪問，Rcmp 提出了一種熱頁面識別和遷移策略，并使用基于鎖的同步機(jī)制來處理細(xì)粒度訪問緩沖。為了改善對遠(yuǎn)程機(jī)架的訪問，Rcmp 設(shè)計(jì)了一個(gè)優(yōu)化的 RRPC 框架。評估結(jié)果表明，Rcmp 在所有工作負(fù)載中表現(xiàn)出色，明顯優(yōu)于其它基于 RDMA 的解決方案，而且沒有額外的開銷。 未來，我們將使用真實(shí)的 CXL 設(shè)備進(jìn)行 Rcmp 實(shí)驗(yàn)，并優(yōu)化去中心化和 CXL 緩存策略的設(shè)計(jì)（見第 6.6 節(jié)）。此外，我們將支持 Rcmp 中的其它存儲設(shè)備（例如 PM、SSD 和 HDD）。

參考資料

[1] GitHub. 2023. FUSE (Filesystem in Userspace). Retrieved December 8, 2023 from http://libfuse.github.io/

[2] Marcos K. Aguilera, Emmanuel Amaro, Nadav Amit, Erika Hunhoff, Anil Yelam, and Gerd Zellweger. 2023. Memory disaggregation: Why now and what are the challenges. ACM SIGOPS Operating Systems Review 57, 1 (2023), 38–46.

[3] Emmanuel Amaro, Christopher Branner-Augmon, Zhihong Luo, Amy Ousterhout, Marcos K. Aguilera, Aurojit Panda, Sylvia Ratnasamy, and Scott Shenker. 2020. Can far memory improve job throughput? In Proceedings of the 15th European Conference on Computer Systems. 1–16.

[4] Jonghyun Bae, Jongsung Lee, Yunho Jin, Sam Son, Shine Kim, Hakbeom Jang, Tae Jun Ham, and Jae W. Lee. 2021. FlashNeuron: SSD-enabled large-batch training of very deep neural networks. In Proceedings of the 19th USENIX Conference on File and Storage Technologies (FAST'21). 387–401.

[5] Luiz André Barroso, Jimmy Clidaras, and Urs H?lzle. 2013. The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines (2nd ed.). Synthesis Lectures on Computer Architecture. Morgan & Claypool.

[6] Brad Benton. 2017. CCIX, GEN-Z, OpenCAPI: Overview & comparison. In Proceedings of the OpenFabrics Workshop.

[7] Som S. Biswas. 2023. Role of Chat GPT in public health. Annals of Biomedical Engineering 51, 5 (2023), 868–869.

[8] Jeff Bonwick. 1994. The slab allocator: An object-caching kernel memory allocator. In Proceedings of the USENIX Summer 1994 Technical Conference, Vol. 16. 1–12.

[9] Qingchao Cai, Wentian Guo, Hao Zhang, Divyakant Agrawal, Gang Chen, Beng Chin Ooi, Kian-Lee Tan, Yong Meng Teo, and Sheng Wang. 2018. Efficient distributed memory management with RDMA and caching. Proceedings of the VLDB Endowment 11, 11 (2018), 1604–1617.

[10] Irina Calciu, M. Talha Imran, Ivan Puddu, Sanidhya Kashyap, and Zviad Metreveli. 2021. Rethinking software runtimes for disaggregated memory. In Proceedings of the 18th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments. 2–16.

[11] Wei Cao, Yingqiang Zhang, Xinjun Yang, Feifei Li, Sheng Wang, Qingda Hu, Xuntao Cheng, Zongzhi Chen, Zhenjun Liu, Jing Fang, et al. 2021. PolarDB Serverless: A cloud native database for disaggregated data centers. In Proceedings of the 2021 International Conference on Management of Data. 2477–2489.

[12] Zhichao Cao and Siying Dong. 2020. Characterizing, modeling, and benchmarking RocksDB key-value workloads at Facebook. In Proceedings of the 18th USENIX Conference on File and Storage Technologies (FAST'20).

[13] Yue Cheng, Ali Anwar, and Xuejing Duan. 2018. Analyzing Alibaba's co-located datacenter workloads. In Proceedings of the 2018 IEEE International Conference on Big Data (Big Data'18). IEEE, Los Alamitos, CA, 292–297.

[14] Adrian Cockcroft. 2023. Supercomputing Predictions: Custom CPUs, CXL3.0, and Petalith Architectures. Retrieved December 8, 2023 from https://adrianco.medium.com/supercomputing-predictions-custom-cpus-cxl3-0-and-petalitharchitectures-b67cc324588f/

[15] Brian F. Cooper, Adam Silberstein, Erwin Tam, Raghu Ramakrishnan, and Russell Sears. 2010. Benchmarking cloud serving systems with YCSB. In Proceedings of the 1st ACM Symposium on Cloud Computing. 143–154.

[16] Anritsu Corporation and KYOCERA Corporation. 2023. PCI Express5.0 Optical Signal Transmission Test. Retrieved December 8, 2023 from https://global.kyocera.com/newsroom/news/2023/000694.html

[17] Aleksandar Dragojevi?, Dushyanth Narayanan, Miguel Castro, and Orion Hodson. 2014. FaRM: Fast remote memory. In Proceedings of the 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI'14). 401–414.

[18] Zhuohui Duan, Haikun Liu, Haodi Lu, Xiaofei Liao, Hai Jin, Yu Zhang, and Bingsheng He. 2021. Gengar: An RDMAbased distributed hybrid memory pool. In Proceedings of the 2021 IEEE 41st International Conference on Distributed Computing Systems (ICDCS'21). IEEE, Los Alamitos, CA, 92–103.

[19] Luciano Floridi and Massimo Chiriatti. 2020. GPT-3: Its nature, scope, limits, and consequences. Minds and Machines 30 (2020), 681–694.

[20] Peter Xiang Gao, Akshay Narayan, Sagar Karandikar, Jo?o Carreira, Sangjin Han, Rachit Agarwal, Sylvia Ratnasamy, and Scott Shenker. 2016. Network requirements for resource disaggregation. In Proceedings of the 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI'16). 249–264. https://www.usenix.org/conference/ osdi16/technical-sessions/presentation/gao

[21] Donghyun Gouk, Sangwon Lee, Miryeong Kwon, and Myoungsoo Jung. 2022. Direct access, high-performance memory disaggregation with DirectCXL. In Proceedings of the 2022 USENIX Annual Technical Conference (USENIX ATC'22). 287–294.

[22] Juncheng Gu, Youngmoon Lee, Yiwen Zhang, Mosharaf Chowdhury, and Kang G. Shin. 2017. Efficient memory disaggregation with INFINISWAP. In Proceedings of the 14th USENIX Conference on Networked Systems Design and Implementation (NSDI'17). 649–667.

[23] Patrick Hunt, Mahadev Konar, Flavio Paiva Junqueira, and Benjamin Reed. 2010. ZooKeeper: Wait-free coordination for internet-scale systems. In Proceedings of the USENIX Annual Technical Conference, Vol. 8.

[24] Anuj Kalia, Michael Kaminsky, and David Andersen. 2019. Datacenter RPCs can be general and fast. In Proceedings of the 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI'19). 1–16.

[25] Anuj Kalia, Michael Kaminsky, and David G. Andersen. 2014. Using RDMA efficiently for key-value services. In Proceedings of the 2014 ACM Conference on SIGCOMM. 295–306.

[26] Anuj Kalia, Michael Kaminsky, and David G. Andersen. 2016. FaSST: Fast, scalable and simple distributed transactions with two-sided (RDMA) datagram RPCs. In Proceedings of the 12th USENIX Conference on Operating Systems Design and Implementation (OSDI'16). 185–201.

[27] Kostas Katrinis, Dimitris Syrivelis, Dionisios Pnevmatikatos, Georgios Zervas, Dimitris Theodoropoulos, Iordanis Koutsopoulos, Kobi Hasharoni, Daniel Raho, Christian Pinto, F. Espina, et al. 2016. Rack-scale disaggregated cloud data centers: The dReDBox project vision. In Proceedings of the 2016 Design, Automation, and Test in Europe Conference and Exhibition (DATE'16). IEEE, Los Alamitos, CA, 690–695.

[28] Youngeun Kwon and Minsoo Rhu. 2018. Beyond the memory wall: A case for memory-centric HPC system for deep learning. In Proceedings of the 2018 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO'18). IEEE, Los Alamitos, CA, 148–161.

[29] Seung-Seob Lee, Yanpeng Yu, Yupeng Tang, Anurag Khandelwal, Lin Zhong, and Abhishek Bhattacharjee. 2021. Mind: In-network memory management for disaggregated data centers. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles. 488–504.

[30] Huaicheng Li, Daniel S Berger, Lisa Hsu, Daniel Ernst, Pantea Zardoshti, Stanko Novakovic, Monish Shah, Samir Rajadnya, Scott Lee, Ishwar Agarwal, et al. 2023. Pond: CXL-based memory pooling systems for cloud platforms. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Vol. 2. 574–587.

[31] Hosein Mohammadi Makrani, Setareh Rafatirad, Amir Houmansadr, and Houman Homayoun. 2018. Main-memory requirements of big data applications on commodity server platform. In Proceedings of the 2018 18th IEEE/ACM International Symposium on Cluster, Cloud, and Grid Computing (CCGRID'18). IEEE, Los Alamitos, CA, 653–660.

[32] Hasan Al Maruf, Hao Wang, Abhishek Dhanotia, Johannes Weiner, Niket Agarwal, Pallab Bhattacharya, Chris Petersen, Mosharaf Chowdhury, Shobhit Kanaujia, and Prakash Chauhan. 2023. TPP: Transparent page placement for CXL-enabled tiered-memory. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Vol. 3. 742–755.

[33] Hasan Al Maruf, Yuhong Zhong, Hongyi Wang, Mosharaf Chowdhury, Asaf Cidon, and Carl Waldspurger. 2021. Memtrade: A disaggregated-memory marketplace for public clouds. arXiv preprint arXiv:2108.06893 (2021).

[34] Satoshi Matsuoka, Jens Domke, Mohamed Wahib, Aleksandr Drozd, and Torsten Hoefler. 2023. Myths and legends in high-performance computing. International Journal of High Performance Computing Applications 37, 3-4 (2023), 245–259.

[35] George Michelogiannakis, Benjamin Klenk, Brandon Cook, Min Yee Teh, Madeleine Glick, Larry Dennison, Keren Bergman, and John Shalf. 2022. A case for intra-rack resource disaggregation in HPC. ACM Transactions on Architecture and Code Optimization 19, 2 (2022), 1–26.

[36] Sumit Kumar Monga, Sanidhya Kashyap, and Changwoo Min. 2021. Birds of a feather flock together: Scaling RDMA RPCs with Flock. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles. 212–227.

[37] Ivy Peng, Roger Pearce, and Maya Gokhale. 2020. On the memory underutilization: Exploring disaggregated memory on HPC systems. In Proceedings of the 2020 IEEE 32nd International Symposium on Computer Architecture and High Performance Computing (SBAC-PAD'20). IEEE, Los Alamitos, CA, 183–190.

[38] The Next Platform. 2022. Just How Bad Is CXL Memory Latency? Retrieved December 8, 2023 from https://www. nextplatform.com/2022/12/05/just-how-bad-is-cxl-memory-latency/

[39] Amanda Raybuck, Tim Stamler, Wei Zhang, Mattan Erez, and Simon Peter. 2021. HeMem: Scalable tiered memory management for big data applications and real NVM. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles. 392–407.

[40] Charles Reiss, Alexey Tumanov, Gregory R. Ganger, Randy H. Katz, and Michael A. Kozuch. 2012. Heterogeneity and dynamicity of clouds at scale: Google trace analysis. In Proceedings of the 3rd ACM Symposium on Cloud Computing. 1–13.

[41] Zhenyuan Ruan, Malte Schwarzkopf, Marcos K. Aguilera, and Adam Belay. 2020. AIFM: High-performance, application-integrated far memory. In Proceedings of the 14th USENIX Conference on Operating Systems Design and Implementation. 315–332.

[42] Rick Salmonson, Troy Oxby, Larry Briski, Robert Normand, Russell Stacy, and Jeffrey Glanzman. 2019. PCIe Riser Extension Assembly. Technical Disclosure Commons (January 11, 2019). https://www.tdcommons.org/dpubs_series/1878

[43] Alex Shamis, Matthew Renzelmann, Stanko Novakovic, Georgios Chatzopoulos, Aleksandar Dragojevi?, Dushyanth Narayanan, and Miguel Castro. 2019. Fast general distributed transactions with opacity. In Proceedings of the 2019 International Conference on Management of Data. 433–448.

[44] Yizhou Shan, Yutong Huang, Yilun Chen, and Yiying Zhang. 2018. LegoOS: A disseminated, distributed OS for hardware resource disaggregation. In Proceedings of the 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI'18). 69–87.

[45] Debendra Das Sharma and Ishwar Agarwal. 2022. Compute Express Link. Retrieved December 8, 2023 from https: //www.computeexpresslink.org/_files/ugd/0c1418_a8713008916044ae9604405d10a7773b.pdf/

[46] Navin Shenoy. 2023. A Milestone in Moving Data. Retrieved December 8, 2023 from https://www.intel.com/content/ www/us/en/newsroom/home.html

[47] Vishal Shrivastav, Asaf Valadarsky, Hitesh Ballani, Paolo Costa, Ki Suh Lee, Han Wang, Rachit Agarwal, and Hakim Weatherspoon. 2019. Shoal: A network architecture for disaggregated racks. In Proceedings of the 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI'19). 255–270. https://www.usenix.org/conference/ nsdi19/presentation/shrivastav

[48] Intel. 2019. Intel Rack Scale Design (Intel RSD) Storage Services. API Specification. Intel.

[49] Yan Sun, Yifan Yuan, Zeduo Yu, Reese Kuper, Ipoom Jeong, Ren Wang, and Nam Sung Kim. 2023. Demystifying CXL memory with genuine CXL-ready systems and devices. arXiv preprint arXiv:2303.15375 (2023).

[50] Torvalds. 2023. Linux Kernel Source Tree. Retrieved December 8, 2023 from https://github.com/torvalds/linux/blob/ master/lib/kfifo.c

[51] Shin-Yeh Tsai, Yizhou Shan, and Yiying Zhang. 2020. Disaggregating persistent memory and controlling them remotely: An exploration of passive disaggregated key-value stores. In Proceedings of the 2020 USENIX Annual Technical Conference. 33–48.

[52] Stephen Van Doren. 2019. HOTI 2019: Compute express link. In Proceedings of the 2019 IEEE Symposium on HighPerformance Interconnects (HOTI'19). IEEE, Los Alamitos, CA, 18–18.

[53] Alexandre Verbitski, Anurag Gupta, Debanjan Saha, Murali Brahmadesam, Kamal Gupta, Raman Mittal, Sailesh Krishnamurthy, Sandor Maurice, Tengiz Kharatishvili, and Xiaofeng Bao. 2017. Amazon Aurora: Design considerations for high throughput cloud-native relational databases. In Proceedings of the 2017 ACM International Conference on Management of Data. 1041–1052.

[54] Midhul Vuppalapati, Justin Miron, Rachit Agarwal, Dan Truong, Ashish Motivala, and Thierry Cruanes. 2020. Building an elastic query engine on disaggregated storage. In Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI'20). 449–462.

[55] Jacob Wahlgren, Maya Gokhale, and Ivy B. Peng. 2022. Evaluating emerging CXL-enabled memory pooling for HPC systems. arXiv preprint arXiv:2211.02682 (2022).

[56] Chenjiu Wang, Ke He, Ruiqi Fan, Xiaonan Wang, Wei Wang, and Qinfen Hao. 2023. CXL over Ethernet: A novel FPGA-based memory disaggregation design in data centers. In Proceedings of the 2023 IEEE 31st Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM'23). IEEE, Los Alamitos, CA, 75–82.

[57] Xingda Wei, Rong Chen, and Haibo Chen. 2020. Fast RDMA-based ordered key-value store using remote learned cache. In Proceedings of the 14th USENIX Conference on Operating Systems Design and Implementation. 117–135.

[58] Qin Xin, Ethan L. Miller, Thomas Schwarz, Darrell D. E. Long, Scott A. Brandt, and Witold Litwin. 2003. Reliability mechanisms for very large storage systems. In Proceedings of the 2003 20th IEEE/11th NASA Goddard Conference on Mass Storage Systems and Technologies (MSST'03). IEEE, Los Alamitos, CA, 146–156.

[59] Juncheng Yang, Yao Yue, and K. V. Rashmi. 2020. A large scale analysis of hundreds of in-memory cache clusters at Twitter. In Proceedings of the 14th USENIX Conference on Operating Systems Design and Implementation. 191–208.

[60] Qirui Yang, Runyu Jin, Bridget Davis, Devasena Inupakutika, and Ming Zhao. 2022. Performance evaluation on CXLenabled hybrid memory pool. In Proceedings of the 2022 IEEE International Conference on Networking, Architecture, and Storage (NAS'22). IEEE, Los Alamitos, CA, 1–5.

[61] Yifan Yuan, Jinghan Huang, Yan Sun, Tianchen Wang, Jacob Nelson, Dan R. K. Ports, Yipeng Wang, Ren Wang, Charlie Tai, and Nam Sung Kim. 2023. RAMBDA: RDMA-driven acceleration framework for memory-intensive μs-scale datacenter applications. In Proceedings of the 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA'23). IEEE, Los Alamitos, CA, 499–515.

[62] Erfan Zamanian, Carsten Binnig, Tim Kraska, and Tim Harris. 2016. The end of a myth: Distributed transactions can scale. CoRR abs/1607.00655 (2016). http://arxiv.org/abs/1607.00655

[63] Ming Zhang, Yu Hua, Pengfei Zuo, and Lurong Liu. 2022. FORD: Fast one-sided RDMA-based distributed transactions for disaggregated persistent memory. In Proceedings of the 20th USENIX Conference on File and Storage Technologies (FAST'22). 51–68.

[64] Yifan Zhang, Zhihao Liang, Jianguo Wang, and Stratos Idreos. 2021. Sherman: A write-optimized distributed B+Tree index on disaggregated memory. arXiv preprint arXiv:2112.07320 (2021).

[65] Yingqiang Zhang, Chaoyi Ruan, Cheng Li, Xinjun Yang, Wei Cao, Feifei Li, Bo Wang, Jing Fang, Yuhui Wang, Jingze Huo, et al. 2021. Towards cost-effective and elastic cloud database deployment via memory disaggregation. Proceedings of the VLDB Endowment 14, 10 (2021), 1900–1912.

[66] Tobias Ziegler, Carsten Binnig, and Viktor Leis. 2022. ScaleStore: A fast and cost-efficient storage engine using DRAM, NVMe, and RDMA. In Proceedings of the 2022 International Conference on Management of Data. 685–699.

[67] Pengfei Zuo, Jiazhao Sun, Liu Yang, Shuangwu Zhang, and Yu Hua. 2021. One-sided RDMA-conscious extendible hashing for disaggregated memory. In Proceedings of the USENIX Annual Technical Conference. 15–29.?Received 9 July 2023; revised 12 October 2023; accepted 26 November 2023

審核編輯：黃飛

?