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

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

01.?引言

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

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

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

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

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

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

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

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

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

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

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

設(shè)計(jì)并實(shí)現(xiàn)了Rcmp，一個(gè)新穎的內(nèi)存池系統(tǒng)，通過(guò)結(jié)合RDMA和CXL的優(yōu)勢(shì)，實(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ī)制、熱頁(yè)交換策略和高性能RPC框架。

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

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

02.?背景

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

表1. 典型系統(tǒng)中的內(nèi)存利用率 彈性不足：在單體服務(wù)器中安裝內(nèi)存或CPU資源后，很難對(duì)其進(jìn)行縮小/擴(kuò)大。因此，服務(wù)器配置必須事先規(guī)劃，并且動(dòng)態(tài)調(diào)整通常會(huì)導(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)營(yíng)成本高和能源浪費(fèi)[11, 65]。此外，現(xiàn)代數(shù)據(jù)中心設(shè)備故障頻繁，幾乎每天都會(huì)發(fā)生[13, 40, 58]。采用單體架構(gòu)時(shí)，當(dāng)服務(wù)器內(nèi)的任何一個(gè)硬件組件發(fā)生故障時(shí)，通常整個(gè)服務(wù)器無(wú)法使用。這種粗粒度的故障管理導(dǎo)致了高昂的成本[44]。 為應(yīng)對(duì)這些問(wèn)題，提出了內(nèi)存解耦合的方案，并在學(xué)術(shù)界和工業(yè)界引起了廣泛關(guān)注[3, 17, 21, 43, 51, 56, 63, 66]。內(nèi)存解耦合將數(shù)據(jù)中心中的內(nèi)存資源與計(jì)算資源分離開(kāi)來(lái)，形成通過(guò)快速網(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）則托管大容量?jī)?nèi)存，幾乎沒(méi)有計(jì)算能力。微秒級(jí)延遲網(wǎng)絡(luò)（例如，RDMA）或緩存一致性互連協(xié)議（例如，CXL）通常是從CNs到MNs的物理傳輸方式。

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

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

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

3.1 基于RDMA的方法

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

圖3. 通信測(cè)試

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

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

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

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

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

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

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

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

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

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

問(wèn)題2：高成本。當(dāng)前CXL產(chǎn)品尚未成熟，大多數(shù)研究仍處于仿真階段，包括基于FPGA的原型和使用NUMA節(jié)點(diǎn)的模擬。早期使用FPGA的CXL產(chǎn)品尚未針對(duì)延遲進(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ò)來(lái)克服CXL的機(jī)架距離限制。最先進(jìn)的案例是CXL-over-Ethernet。它將計(jì)算和內(nèi)存池部署在不同的機(jī)架中，并在計(jì)算池中使用CXL提供全局一致內(nèi)存抽象，因此CPU可以通過(guò)Load/Store語(yǔ)義直接訪問(wèn)分離的內(nèi)存。然后，采用以太網(wǎng)來(lái)傳輸CXL內(nèi)存訪問(wèn)請(qǐng)求到內(nèi)存池。這種方法可以支持緩存行訪問(wèn)粒度，但每個(gè)遠(yuǎn)程訪問(wèn)仍然需要網(wǎng)絡(luò)，并且無(wú)法利用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é)合起來(lái)是有前途的研究。在本文中，我們通過(guò)結(jié)合基于CXL和基于RDMA的方法（即，在機(jī)架內(nèi)通過(guò)CXL構(gòu)建小型內(nèi)存池，并通過(guò)RDMA連接這些小型內(nèi)存池）來(lái)探索一種新的混合架構(gòu)。這種對(duì)稱(chēng)架構(gòu)允許在每個(gè)小型內(nèi)存池中充分利用CXL的優(yōu)勢(shì)，并通過(guò)RDMA提高可擴(kuò)展性。然而，這種混合架構(gòu)面臨以下挑戰(zhàn)。

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

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

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

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

4.2 高效通信機(jī)制 如圖4所示，混合架構(gòu)有三種遠(yuǎn)程機(jī)架通信的可選方法。在方法（a）中，每個(gè)計(jì)算節(jié)點(diǎn)通過(guò)自己的 RNIC 訪問(wèn)遠(yuǎn)程機(jī)架中的內(nèi)存池。這種方法有明顯的缺點(diǎn)。首先是高昂的成本，由于過(guò)多的 RNIC 設(shè)備；其次，每個(gè)計(jì)算節(jié)點(diǎn)都有 CXL 鏈接和 RDMA 接口，導(dǎo)致高一致性維護(hù)開(kāi)銷(xiāo)；第三，與有限的 RNIC 內(nèi)存存在高競(jìng)爭(zhēng)，導(dǎo)致頻繁的緩存失效和更高的通信延遲。在方法（b）中，每個(gè)機(jī)架上都使用一個(gè)守護(hù)進(jìn)程服務(wù)器（配備有 RNIC）來(lái)管理對(duì)遠(yuǎn)程機(jī)架的訪問(wèn)請(qǐng)求。守護(hù)進(jìn)程服務(wù)器可以降低成本和一致性開(kāi)銷(xiāo)，但是單個(gè)守護(hù)進(jìn)程（帶有一個(gè) RNIC）將導(dǎo)致有限的 RDMA 帶寬。在方法（c）中，使用哈希將計(jì)算節(jié)點(diǎn)分組，每個(gè)組對(duì)應(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 使用無(wú)鎖環(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ù)存儲(chǔ)位置。簡(jiǎn)單的解決方案是在 CXL 內(nèi)存中維護(hù)一個(gè)環(huán)形緩沖區(qū)，以管理計(jì)算節(jié)點(diǎn)與守護(hù)進(jìn)程之間的通信，這可能會(huì)導(dǎo)致混合架構(gòu)中的消息阻塞。如圖5所示，計(jì)算節(jié)點(diǎn)將訪問(wèn)請(qǐng)求添加到環(huán)形緩沖區(qū)并等待守護(hù)進(jìn)程輪詢(xún)。在此示例中，CN1 首先發(fā)送 Msg1，然后 CN2 發(fā)送 Msg2。當(dāng)數(shù)據(jù)填滿(mǎn)時(shí)，當(dāng)前消息（Msg1）完成，下一個(gè)消息（Msg2）將被處理。如果 Msg1 是一個(gè)遠(yuǎn)程機(jī)架訪問(wèn)請(qǐng)求，而 Msg2 是一個(gè)本地機(jī)架訪問(wèn)請(qǐng)求，那么由于 RDMA 和 CXL 之間的性能差距，可能會(huì)先填滿(mǎn) Msg2。由于每條消息的長(zhǎng)度可變，守護(hù)進(jìn)程無(wú)法獲取 Msg2 的頭指針以跳過(guò) Msg1 并首先處理 Msg2。Msg2 必須等待 Msg1 完成，導(dǎo)致消息阻塞。為避免通信阻塞，Rcmp 將本地和遠(yuǎn)程機(jī)架訪問(wèn)解耦，并使用不同的環(huán)形緩沖區(qū)結(jié)構(gòu)，其中遠(yuǎn)程機(jī)架訪問(wèn)采用雙層環(huán)形緩沖區(qū)。

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

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

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

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

05.?RCMP系統(tǒng)

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

5.1系統(tǒng)概述

Rcmp系統(tǒng)概述如圖6所示。Rcmp以機(jī)架為單位管理集群。機(jī)架內(nèi)所有 CN 和 MN 通過(guò) CXL 鏈接相互連接，形成一個(gè)小的 CXL 內(nèi)存池。不同的機(jī)架通過(guò) RDMA 連接起來(lái)，形成一個(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é)處理訪問(wèn)請(qǐng)求，包括 CXL 請(qǐng)求（CXL 代理）和 RDMA 請(qǐng)求（消息管理器），交換熱頁(yè)（交換管理器），管理 slab 分配器，并維護(hù) CXL 內(nèi)存空間（資源管理器）。Daemon 運(yùn)行在每個(gè)機(jī)架內(nèi)的服務(wù)器上，與 CN 相同。此外，Rcmp 是一個(gè)用戶(hù)級(jí)架構(gòu)，避免了內(nèi)核和用戶(hù)空間之間的上下文切換開(kāi)銷(xiāo)。

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

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

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

表4. Rcmp API

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

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

圖9. Rcmp的工作流程

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

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

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

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

圖11. 熱頁(yè)交換

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

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

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

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

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

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

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

06.?評(píng)估

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

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

6.2 實(shí)驗(yàn)設(shè)置 所有實(shí)驗(yàn)均在五臺(tái)服務(wù)器上進(jìn)行，每臺(tái)服務(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)訪問(wèn)延遲分別為93 ns和89.7 ns。 Rcmp與其它四種最先進(jìn)的遠(yuǎn)程內(nèi)存系統(tǒng)進(jìn)行了比較：（1）Fastswap[3]，一個(gè)基于頁(yè)面的系統(tǒng)；（2）FaRM[17]，一個(gè)基于對(duì)象的系統(tǒng)；（3）GAM[9]，一個(gè)通過(guò)RDMA提供緩存一致性協(xié)議的分布式內(nèi)存系統(tǒng)；以及（4）CXL-over-Ethernet，一個(gè)基于CXL的內(nèi)存解耦合系統(tǒng)，使用以太網(wǎng)（詳情見(jiàn)第7章）。我們使用開(kāi)源代碼運(yùn)行Fastswap和GAM。由于FaRM不是公開(kāi)的，我們使用Cai等人的工作中的代碼[9]。請(qǐng)注意，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原型。為了公平起見(jiàn)，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微秒。我們的測(cè)試環(huán)境如圖13(b)所示。由于設(shè)備有限，我們使用一臺(tái)服務(wù)器模擬一個(gè)機(jī)架，包括一個(gè)小型計(jì)算池和內(nèi)存池（或CXL內(nèi)存）。對(duì)于Rcmp和CXL-over-Ethernet，計(jì)算池在一個(gè)CPU插槽上運(yùn)行，一個(gè)無(wú)CPU的MN作為CXL內(nèi)存。在Rcmp的計(jì)算池中，不同進(jìn)程運(yùn)行不同的CN客戶(hù)端，一個(gè)進(jìn)程運(yùn)行Daemon。對(duì)于其它系統(tǒng)，內(nèi)存池通過(guò)RDMA連接到計(jì)算池。此外，機(jī)架中的內(nèi)存池或CXL內(nèi)存具有約100 GB的DRAM，計(jì)算池的本地DRAM為1 GB。我們使用微基準(zhǔn)測(cè)試評(píng)估不同系統(tǒng)的基本讀/寫(xiě)性能，并使用YCSB基準(zhǔn)測(cè)試[15]評(píng)估它們?cè)诓煌ぷ髫?fù)載下的性能，如表5所示。

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

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

圖14. 訪問(wèn)延遲

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

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

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

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

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

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

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

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

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

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

圖18. 技術(shù)對(duì)性能的貢獻(xiàn) 我們首先逐個(gè)應(yīng)用Rcmp的關(guān)鍵技術(shù)，在雙機(jī)架環(huán)境下的微基準(zhǔn)測(cè)試結(jié)果如圖18所示?；鶞?zhǔn)表示Rcmp的基本版本，包括單層環(huán)形緩沖區(qū)、eRPC等。+RB表示采用雙層環(huán)形緩沖區(qū)；+Swap和+WB表示進(jìn)一步應(yīng)用熱頁(yè)交換和CXL寫(xiě)緩沖區(qū)；+RRPC表示采用RRPC框架，并展示了Rcmp的最終性能。Rcmp-only-CXL表示所有讀/寫(xiě)操作在機(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ū)減少了延遲，尤其是尾部延遲。交換策略極大地降低了延遲，提高了吞吐量，這在讀操作中更為明顯。寫(xiě)緩沖區(qū)和RRPC顯著提高了吞吐量，寫(xiě)緩沖區(qū)主要影響寫(xiě)操作。 然后，我們?cè)敿?xì)分析了每種技術(shù)的好處。默認(rèn)情況下，所有實(shí)驗(yàn)均在雙機(jī)架環(huán)境中運(yùn)行。

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

圖20. 熱頁(yè)交換

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

圖22. RRPC框架

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

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

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

RRPC框架。我們將RRPC與FaRM的RPC [17]、eRPC [24]框架和混合模式（eRPC + 單邊RDMA動(dòng)詞）在不同傳輸數(shù)據(jù)大小下進(jìn)行比較。如圖22所示，當(dāng)傳輸數(shù)據(jù)較大時(shí)，RRPC的吞吐量比eRPC + 單邊RDMA動(dòng)詞高出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只會(huì)在數(shù)據(jù)小于512B時(shí)選擇eRPC方法，并在數(shù)據(jù)較大時(shí)選擇混合模式。此外，RRPC采用了幾種策略來(lái)提高RDMA通信性能。

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

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

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

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

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

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

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

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

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

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

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

審核編輯：黃飛

?