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

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

01.?引言

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

圖1. 內存解耦合

圖2. 不同的內存解耦合架構

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

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

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

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

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

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

總之，我們的工作主要貢獻如下：

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

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

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

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

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

02.?背景

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

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

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

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

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

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

3.1 基于RDMA的方法

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

圖3. 通信測試

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

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

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

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

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

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

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

低延遲：CXL提供接近內存的延遲，基于CXL的方法緩解了網絡瓶頸和內存過度配置的問題。

彈性：基于CXL的方法具有出色的可擴展性，因為可以連接更多的PCIe設備，而不像用于DRAM的DIMM（雙列直插式內存模塊）那樣受限。 然而，基于CXL的方法也存在以下缺點。

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

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

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

表3. 內存解耦合方法比較

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

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

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

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

04.?設計思路

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

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

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

圖4. 機架間通信方法

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

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

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

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

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

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

05.?RCMP系統(tǒng)

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

5.1系統(tǒng)概述

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

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

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

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

表4. Rcmp API

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

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

圖9. Rcmp的工作流程

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

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

圖10. 機架內通信機制

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

圖11. 熱頁交換

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

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

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

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

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

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

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

06.?評估

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

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

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

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

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

表5. YCSB工作負載

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

圖14. 訪問延遲

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

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

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

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

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

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

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

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

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

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

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

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

圖20. 熱頁交換

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

圖22. RRPC框架

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

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

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

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

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

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

07.?相關工作

7.1 基于 RDMA 的遠程內存 基于頁面的系統(tǒng)。

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

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

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

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

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

08.?結論與未來工作

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

審核編輯：黃飛

?