一週一論文（翻譯 總結）—— [SOSP 18] LITE Kernel RDMA Support for Datacenter Applications : 一個LITE 核心支援的RDMA通訊庫
目錄
2. BACKGROUND AND ISSUES OF RDMA
2.2 RDMA in DataCenter Applications
2.3 Issue 1: Mismatch in Abstractions
2.4 Issue 2: Unscalable Performance
2.5 Issue 3: Lack of Resource Sharing, Isolation, and Protection
3. VIRTUALIZING RDMA IN KERNEL: A DESIGN OVERVIEW
4. LITE MEMORY ABSTRACTION AND RDMA
4.1 LITE Memory Abstraction and Management
4.2 LITE RDMA Benefits and Performance
5.2 Optimizations between User-Space and Kernel
5.3 LITE RPC Performance and CPU Utilization
6.2 Resource Isolation and QoS
7.2 Synchronization and Atomic Primitives
8.1 Distributed Atomic Logging
Abstract
最近，人們越來越關注使用RDMA構建資料中心應用程式，因為它具有低延遲，高吞吐量和低CPU利用率的優勢。 但是，RDMA並不適合資料中心應用。 它缺乏靈活的高階抽象; 它的表現不規模; 它不提供資源共享或靈活的保護。 由於存在這些問題，很難構建基於RDMA的應用程式並利用RDMA的效能優勢。
為了解決這些問題，我們在Linux核心中構建了LITE，一個用於RDMA的本地間接TiEr，它將原生RDMA虛擬化為靈活，高階，易用的抽象，並允許應用程式安全地共享資源。 儘管人們普遍認為核心旁路對於RDMA的低延遲效能至關重要，但我們表明，使用核心級間接可以同時實現靈活性和低延遲，可擴充套件的效能。 為了展示LITE的優勢，我們在LITE上開發了幾個流行的資料中心應用程式，包括圖形引擎，MapReduce系統，分散式共享記憶體系統和分散式原子日誌系統。 這些系統易於構建並提供良好的效能。 例如，我們的PowerGraph實現僅使用20行LITE程式碼，同時表現優於PowerGraph 3.5倍至5.6倍。
1. Introduction
遠端直接記憶體訪問（RDMA）是通過網路直接訪問遠端計算機上的記憶體的能力。 RDMA提供低延遲，高頻寬和低CPU利用率，並且已經在高效能運算環境中被廣泛採用多年[32,51,55]。
由於資料中心應用對低延遲網路通訊的需求以及對RDMA [12,17,28,41,42,54,57,60]的更成熟的硬體支援，學術界和工業界越來越感興趣 近年來，建立基於RDMA的資料中心應用[6,11,19,20,37-39,52,58,69,70,77,78,81,82]。
儘管RDMA中的許多設計選擇都適合像HPC這樣的受限制的單用途環境，但原生RDMA（即未經修改的RDMA硬體，驅動程式和預設庫）並不適合更通用的，異構的，以及大規模資料中心環境由於以下三個原因。
首先，Native RDMA提供的抽象與資料中心應用所需的基本不匹配。 資料中心應用程式通常建立在高階抽象的基礎上，但原生RDMA提供了一個接近硬體基元的低階抽象。 因此，資料中心應用程式使用RDMA並不容易，甚至更難以利用RDMA的所有效能優勢。 大多數基於RDMA的資料中心應用程式需要定製的RDMA軟體堆疊[19,20,37-39,58]，大量的應用程式適配[6,70,81]或RDMA驅動程式的變化[19,39].
Native RDMA不適合資料中心使用的第二個原因是因為沒有軟體來管理或保護RDMA資源。 RDMA在硬體級別管理和保護資源，並允許使用者級應用程式直接向繞過核心的RDMA NIC（稱為RNIC）發出請求。 此設計至少導致資料中心應用程式的三個缺點：缺乏資源共享，效能隔離不足以及保護不靈活.
第三個問題是RDMA的當前架構無法提供與資料中心應用程式的記憶體使用量相稱的效能。 繞過核心時，RDMA通過將特權操作和元資料移動到硬體，不可避免地增加了RNIC的負擔。 例如，RNIC在其SRAM中儲存使用者儲存區域的保護金鑰和快取頁表條目。 這種架構基本上很難滿足資料中心應用的儲存器使用需求，因為RN-ROM記憶體容量的增加很慢，並且成本和能源效率低下。
上述所有問題的根本原因是RDMA設計允許應用程式直接訪問硬體RNIC。 雖然這種設計可以最大限度地減少軟體開銷，但它所引起的問題將在很大程度上限制RDMA在資料中心的採用。
我們在核心空間中構建了LITE，一個本地間接TiEr，用於虛擬化和管理資料中心應用程式的RDMA。 LITE將記憶體組織為虛擬記憶體區域，並支援豐富的API集，包括各種記憶體操作，RPC，訊息傳遞和同步原語。 作為核心空間，LITE可以安全地管理特權資源，提供靈活的保護，並保證跨應用程式的效能隔離。 圖1和圖2說明了原生RDMA和LITE的體系結構。
首先，我們僅在本地節點新增一個間接級別，並且仍然確保單邊RDMA操作直接訪問遠端記憶體。 其次，我們只將特權資源的管理從硬體載入到核心，並將其餘的網路堆疊留在硬體上。 這樣做不僅可以保留原生RDMA的效能，還可以解決由有限的RNIC SRAM引起的效能可擴充套件性問題。 第三，我們通過直接使用實體地址定址使用者記憶體來避免使用者和核心空間之間的記憶體複製。 最後，我們設計了幾種優化技術來最小化系統呼叫開銷。
在內部，LITE由RDMA堆疊和RPC堆疊組成。 RDMA堆疊通過執行自己的地址對映和許可權檢查來管理LITE的記憶體抽象。 通過這種間接級別，我們可以安全地從RNIC中刪除這兩個功能以及由此產生的可擴充套件性瓶頸，而無需對RNIC或驅動程式進行任何更改。 LITE使用基於雙邊RDMA的新機制實現RPC，同時實現了靈活性，良好效能，低CPU利用率和高效的記憶體空間使用。 在這兩個堆疊的頂部，我們實現了一組擴充套件的更高階功能和QoS機制。
我們的評估表明，與原生RDMA和針對特定應用定製的現有解決方案[38,39]相比，LITE提供了類似的延遲和吞吐量，同時提高了靈活性，效能可擴充套件性，CPU利用率，資源共享和服務質量。
我們通過在LITE上構建四個分散式應用程式進一步證明了LITE的易用性，靈活性和效能優勢：原子日誌系統，MapRecece系統，圖形引擎和核心級分散式共享記憶體（DSM） ）系統。 這些系統易於構建且效能良好。 例如，我們的圖形引擎實現只有20行LITE程式碼，它們包含了所有網路通訊功能。 在使用與PowerGraph [25]相同的設計時，這種基於LITE的圖形引擎的效能優於PowerGraph 3.5倍至5.6倍。 我們的基於LITE的MapReduce是從單節點MapRecece實現[65]移植而來的，有49行LITE程式碼，它優於Hadoop [1] 4.3×到5.3×。
總的來說，本文做出了以下重要貢獻：
我們確定了在資料中心環境中使用本機RDMA的三個主要問題及其根本原因。
•我們是第一個建議使用通用核心級間接層為資料中心RDMA應用程式虛擬化RDMA。
•我們設計了一套機制來最小化核心級間接的效能開銷，並展示了在保留（甚至改進）其效能的同時虛擬化RDMA的可能性。
•我們構建了LITE系統，該系統解決了資料中心應用程式的所有三個問題。 資料中心應用程式可以輕鬆使用LITE執行低延遲網路通訊和分散式操作。 RNIC可以依靠LITE來管理和保護其資源，從而降低其硬體複雜性和RNIC記憶體。
•我們在LITE上開發了四個資料中心應用程式，評估了它們的效能，並總結了我們的應用程式程式設計經驗。
2. BACKGROUND AND ISSUES OF RDMA
本節簡要介紹了RDMA，它在資料中心中的用法，以及它對資料中心應用程式的限制。 圖1說明了原生RDMA的體系結構以及應用程式如何使用它。
2.1 Background on RDMA
RDMA允許使用者空間應用程式直接讀取或寫入遠端記憶體，而無需核心干擾或記憶體複製。 RDMA支援單面和雙面通訊。 單向RDMA操作直接在遠端節點上訪問記憶體，而不涉及遠端節點的CPU。 雙向RDMA操作向遠端節點通知傳遞的訊息。
RDMA支援可靠和不可靠的連線（RC和UC）和不可靠的資料報（UD）。 原生RDMA的標準介面是一組統稱為Verbs的操作。 本機RDMA允許使用Verbs從使用者空間和核心空間進行訪問。
RDMA通訊使用各種型別的佇列來實現。通過在兩個節點之間構建一對Queue Pair來建立RC通訊，稱為Queue Pair（QP）。要執行單邊RDMA操作，遠端節點上的應用程式程序需要首先註冊記憶體區域（MR），獲取遠端MR保護金鑰（稱為rkey），並傳送遠端MR的虛擬地址和它到本地節點的rkey。本地主機還需要為讀/寫緩衝區註冊本地MR，然後可以通過在傳送佇列（SQ）上釋出請求來執行RDMA操作。一旦請求傳送到RNIC，RDMA READ/WRITE操作就會返回。應用程式必須單獨輪詢傳送完成佇列（CQ）以瞭解何時已讀取或寫入遠端資料。要執行雙邊RDMA操作，遠端主機需要在本地主機發送訊息之前將接收緩衝區預先發布到接收佇列（RQ）。遠端主機輪詢接收CQ以識別所接收的訊息。
RDMA有三種實現：InfiniBand（IB）[34]，RoCE [33]和iWARP [67]。 IB是專為RDMA設計的交換網路。 RoCE和iWARP是兩種基於乙太網的技術，也提供RDMA Verbs介面。 由於LITE建立在Verbs介面之上，因此它適用於RDMA的所有這些實現。
2.2 RDMA in DataCenter Applications
過去二十年來，在HPC環境中越來越多地使用RDMA [32,51,55]。 近年來，在工業界和學術界的資料中心環境中使用RDMA的趨勢正在出現[2,7,15,27]。 最近基於RDMA的應用包括鍵值儲存系統[19,37-39,58]，DSM系統[19,59]，資料庫和事務系統[6,11,20,78,81]，圖形儲存系統[70] ]，共識系統[77]和分散式NVM系統[52,69,82].
我們相信，由於應用需求和硬體支援，在資料中心中使用RDMA將在未來繼續增加。 許多現代資料中心應用程式要求快速訪問大量資料，最方便，最有效地作為記憶體資料。 由於單個機器上的記憶體面向牆壁[31]，這些應用程式可以從快速，直接訪問遠端儲存器中獲益[27,59,61]。 與此同時，資料中心的更多硬體正在增加對直接RDMA訪問的支援，例如NVMe over Fabrics [12,57]和GPU Direct [17,41,54,60]。
RDMA的許多設計選擇在HPC等受控的專用環境中執行良好。 但是，資料中心環境的不同之處在於它們需要支援異構的，大規模的，快速發展的應用程式。 使用本機RDMA進行資料中心應用有幾個問題，我們將在§2.3，§2.4和§2.5中討論。
2.3 Issue 1: Mismatch in Abstractions
RDMA不易使用的一個主要原因是它的抽象與資料中心應用程式所需的不匹配。 與開發人員可以將一個或幾個應用程式精心調整為專用硬體的HPC環境不同，資料中心應用程式開發人員需要一種高階，易用，靈活的網路通訊抽象，以便他們可以專注於特定於應用程式的開發。 最初是為HPC環境設計的，原生RDMA使用接近硬體原型的低階抽象，很難使用[38]。 應用程式必須明確地管理各種型別的資源，並通過幾個非直觀的步驟來執行RDMA操作，如第2.1節中所述。 優化RDMA效能甚至更加困難。 使用者需要從不同的RDMA操作選項中正確選擇並調整各種配置，有時甚至採用低階優化技術[19,38,39]。
本機RDMA介面之上的API包裝器（如Rsocket [30]）可以將某些RDMA API轉換為高階API。 但是，對於資料中心應用程式來說，這樣一個簡單的包裝器是遠遠不夠的。 例如，使用應用程式程序地址空間中的虛擬記憶體地址建立和訪問RDMA記憶體區域。 虛擬記憶體地址的使用要求RNIC儲存用於地址對映的頁表條目（PTE）（第2.4節），使得難以跨程序共享資源（第2.5節），並且不能維持程序崩潰。 API包裝器無法解決任何這些問題，因為它們不會改變RNIC使用虛擬記憶體地址的方式。
2.4 Issue 2: Unscalable Performance
繞過核心時，特權操作和資料結構被解除安裝到硬體RNIC。 對於有限的RNIC SRAM，RDMA效能基本上難以根據三個因素進行擴充套件：MR的數量，MR的總大小以及QP的總數。
首先，RNIC為所有已註冊的MR儲存lkeys，rkeys和虛擬記憶體地址。隨著MR數量的增加，RNIC將很快（在我們的實驗中超過100 MR）面臨記憶壓力（圖4）。由於每個MR都是一個連續的虛擬記憶體範圍，並且只支援一個許可權，因此無法使用多個MR在很大程度上限制了RDMA的靈活性。例如，許多鍵值儲存系統使用非連續的記憶體區域來儲存資料。 Memcached [21]以1MB為單位執行按需記憶體分配，並使用64MB預分配記憶體塊優化記憶體分配。即使預分配，也需要至少1000 MR用於64 GB資料。 Masstree [53]為每個值使用單獨的記憶體區域，並且可能佔用多達1.4億個記憶體區域。這些場景使用MR遠遠超過RNIC可以處理而不會失去效能。使用更大的MR可以減少MR的總數，但需要大量的應用程式更改，並且可能導致記憶體空間浪費[49]。
其次，RNIC快取用於MR的PTE以從其虛擬儲存器地址獲得RDMA請求的DMA地址。 當RNIC中存在PTE未命中時，RNIC將從主機OS獲取PTE。 當註冊的MR的總大小超過RNIC可以處理的大小（在圖5中的實驗中超過4MB）時，將發生顛簸並降低效能。 不幸的是，大多數資料中心應用程式使用大量記憶體。 例如，使用GraphX [26]和Spark [80]在1.3 GB資料集上執行PageRank [45]將分別需要12 GB和16 GB記憶體堆[27]。 FaRM [19]使用2 GB大頁面來緩解MR大小的可擴充套件性問題。 但是，使用大頁面會導致記憶體佔用量增加，實體記憶體碎片化，虛假記憶體共享以及NUMA效能下降[22,44,75]。
最後，RNIC將每個QP的元資料儲存在其記憶體中。 當QP數量增加時，RDMA效能下降[19]，這在很大程度上限制了RDMA叢集中可通過RC連線的節點總數。 FaSST [39]使用UD來減少QP的數量。 但UD不可靠，不支援單側RDMA。
資料中心應用程式通常需要以上三種類型的可伸縮性。 即使單個應用程式的規模很小，多個應用程式的組合也可能會導致可伸縮性問題。 RNIC記憶體增加的速度落後於資料中心應用程式日益增加的可擴充套件性。 此外，大型的RNIC記憶體在成本和能源效率方面都很低[68]。 我們認為將所有特權功能和元資料解除安裝到硬體上並不是也不會是將RDMA用於資料中心應用的可行方法。 相反，需要重構RDMA軟體和硬體堆疊。
2.5 Issue 3: Lack of Resource Sharing, Isolation, and Protection
Native RDMA不提供任何安全共享資源的機制，例如QP，CQ，記憶體緩衝區，跨不同應用程式的輪詢執行緒; 它只提供了在程序中共享接收佇列（稱為SRQ）的機制。 每個應用程式程序都必須構建和管理自己的資源集。
缺乏資源共享使得上述效能可伸縮性問題更加嚴重。 例如，兩個節點上的每對程序需要構建至少一個QP來執行RC操作。 為了對雙邊RDMA執行輪詢，每個節點需要每個程序至少一個執行緒來忙於輪詢單獨的接收CQ。 在流程中共享資源[19]提高了可伸縮性，但範圍有限。
如果沒有全域性資源管理，很難將效能隔離併為不同的應用程式提供服務質量（QoS）。 例如，應用程式可以簡單地註冊大量MR以填充RNIC的內部儲存器，並影響使用RNIC的所有其他應用程式的效能。
RDMA使用lkeys和rkeys保護MR。 但是，這種保護並不靈活。 每個MR只能註冊一個許可權，所有應用程式都使用該許可權來訪問MR。 要更改MR的許可，需要取消註冊並重新註冊。 此外，本機RDMA依賴於使用者應用程式來傳遞節點之間的MR的rkeys和儲存器地址。 未加密的rkeys和地址可能會導致安全漏洞[46]。
3. VIRTUALIZING RDMA IN KERNEL: A DESIGN OVERVIEW
“電腦科學中的所有問題都可以通過另一層次的間接解決” - 通常歸功於巴特勒蘭普森，後者將其歸功於大衛惠勒
上一節概述了原生RDMA的問題，即1）沒有高階抽象，2）由於容易過載的RNIC記憶體而導致的不可擴充套件的效能，以及3）缺乏資源管理，彼此正交。 但是，它們都指向相同的解決方案：RDMA的虛擬化和管理層。 這樣的層對於使RDMA適用於資料中心應用至關重要。 本節討論新增核心級別指示的原因和方式，新增此類間接層的挑戰，以及LITE設計和體系結構的概述。
3.1 Kernel-Level Indirection
§2中討論的許多RDMA問題已在幾十年前進行過探索，具有不同型別的硬體資源。 諸如DRAM和磁碟之類的硬體裝置暴露了低階硬體原語，這些原語難以直接由應用程式使用。 虛擬記憶體系統和檔案系統通過在核心空間中虛擬化，保護和管理這些硬體資源來解決這些問題。 我們相信，我們可以使用間接和虛擬化的相同經典智慧，使本機RDMA為資料中心應用程式的使用做好準備。
我們建議使用核心空間中的間接級別來虛擬化RDMA。 間接層可以將本機RDMA的低階抽象轉換為資料中心應用程式的高階，易用的抽象。 核心級間接層可以安全地管理所有特權資源。 因此，它可以將元資料和操作從硬體移動到軟體。 這樣做很大程度上降低了RNIC的記憶體壓力，並提高了基於RDMA的資料中心應用程式的可擴充套件性，這些應用程式目前受到RNIC SRAM大小的限制。 此外，核心間接層可以同時服務於核心級應用程式和使用者級應用程式。
3.2 Challenges
為資料中心應用程式構建高效，靈活的核心級RDMA間接層並不容易。 至少有三個獨特的挑戰。
最大的挑戰是如何在增加支援資料中心應用程式所需的間接性的同時保持RDMA的效能優勢？
接下來，我們如何在提供良好效能的同時使LITE具有通用性和靈活性？ LITE的抽象和實現都需要支援廣泛的資料中心應用程式。 LITE還需要讓應用程式安全有效地共享資源。 與以前的作品[19,20,37-39]不同，我們不能使用針對特定型別的應用定製的抽象或優化技術。
最後，我們可以在不改變現有硬體，驅動程式或OS的情況下新增核心級間接嗎？ 為了更容易採用LITE，LITE不應要求更改現有的系統軟體或硬體。 理想情況下，它應該包含在獨立的核心可載入模組中。
3.3 LITE Overall Architecture
LITE在核心空間中使用一個間接級別來實現RDMA的虛擬化。 它為所有使用LITE的應用程式管理和虛擬化RDMA資源（不想使用LITE的應用程式仍然可以直接在同一臺機器上訪問本機RDMA）。 LITE使用標準的Verbs抽象與RDMA驅動程式和RNIC進行對話。 圖2展示了LITE的整體架構。 我們在3.11.1 Linux核心中實現了LITE作為可載入核心模組，具有大約15K行程式碼。
總的來說，LITE實現了以下設計目標。
•LITE為各種資料中心應用程式提供靈活且易於使用的抽象。
•LITE保留了RDMA的三個效能優勢：低延遲，高頻寬和低CPU利用率。
•LITE的效能比原生RDMA更好。
•LITE提供細粒度和靈活的保護。
•使用LITE共享RDMA資源並輕鬆隔離效能非常有效。
•LITE不需要更改硬體，驅動程式或作業系統。
LITE支援三種類型的介面：memory-like的操作，RPC和訊息傳遞以及同步原語，它支援核心級和使用者級應用程式。 我們選擇了這些語義，因為它們對資料中心應用程式設計師來說很熟悉。 大多數LITE API在現有記憶體，分散式和網路系統中都有其對應物。 表1列出了LITE的主要API。
在內部，LITE由兩個主要軟體堆疊組成：單邊RDMA操作的自定義實現（§4），以及基於雙邊RDMA操作的RPC功能和訊息傳遞的堆疊（第5節）。 這些部分共享許多資源，例如QP，CQ和LITE內部執行緒（第6節）。
我們的安全模型是信任LITE而不是任何LITE使用者。 例如，LITE不允許使用者自己傳遞MR資訊，從而避免了以明文形式傳遞rkeys的安全漏洞（§2.5）。 我們當前的安全模型的改進是可能的，例如，通過減少物理儲存空間LITE控制或利用MPK [14]等技術。 我們留待將來的工作。
3.4 LITE Design Principles
在我們詳細討論LITE內部結構之前，我們概述了幫助我們實現設計目標的設計原則。 通用層具有虛擬化，靈活的抽象。 LITE提供靈活的高階抽象，可以輕鬆地用於各種應用程式。 我們將LITE API設計為一組通用API，資料中心應用程式可以在其上進一步構建自定義API。 具體來說，我們將記憶體，連線和佇列管理從應用程式解除安裝到LITE。 這一組最小的LITE API包含保護並將其移至使用者空間可能會導致安全漏洞或需要不靈活的硬體輔助機制[5,63]。
通過載入軟體高效的功能，避免硬體中的冗餘間接。 使用核心級別的指示並不一定意味著增加一個級別的指示。 我們刪除當前存在於硬體RNIC中的間接，以避免冗餘間接。 具體來說，我們將兩個功能從硬體載入到LITE：記憶體地址對映和保護。 我們將剩餘的RDMA堆疊（例如硬體佇列）留在RNIC。 從硬體中刪除這兩個功能不僅可以消除冗餘間接的開銷，還可以最大限度地減少硬體記憶體壓力，從而提高RDMA在應用程式記憶體使用方面的可擴充套件性（§2.4）。 同時，僅載入這兩個功能並不會給主機增加太多負擔並保留RDMA的良好效能，我們將在§4.2中看到。
僅在本地側新增間接進行單邊操作。 使用單邊RDMA的直接遠端記憶體訪問可以完全消除遠端節點上的CPU利用率。 為了保留這個好處，我們建議只在本地節點新增一個間接層。 正如我們將在§4中所示，本地間接層是解決本機單邊RDMA操作問題所需的全部內容。
避免硬體或驅動程式更改。 需要在不改變硬體的情況下移除硬體級間接，但這並不容易。 幸運的是，我們確定了一種與實體記憶體地址進行RNIC互動的方法。 基於這種機制，我們提出了一種新技術，可以在不改變硬體的情況下最大限度地減少硬體間接（第4.1節）。
隱藏核心成本開銷。 我們設計了幾種技術來通過將大部分開銷從效能關鍵路徑上移除來隱藏系統呼叫開銷（第5.2節）。 與以前的輕量級系統呼叫解決方案不同[73]，我們的方法不需要對現有作業系統進行任何更改。 LITE使用地址重新對映和分散 - 收集列表來避免記憶體複製。 最後，LITE允許傳送方應用程式執行緒執行到最後，以避免任何執行緒排程成本。
接下來的幾節組織如下。 §4和§5詳細描述了LITE的單邊RDMA和RPC堆疊。 §4還介紹了LITE使用的新虛擬化記憶體抽象。 §6討論了LITE的資源共享和QoS機制。 §7簡要介紹了我們在LMA中新增RDMA和RPC堆疊的幾個擴充套件功能。
本文其餘部分的所有實驗均在10臺機器的叢集中進行，每臺機器配備兩臺Intel Xeon E5-2620 2.40GHz CPU，128 GB DRAM和一臺40 Gbps Mellanox ConnectX-3 NIC。 40Gbps Mellanox InfiniBand交換機連線這些機器的IB鏈路。
4. LITE MEMORY ABSTRACTION AND RDMA
本節介紹LITE的記憶體抽象及其支援靈活單側RDMA操作的機制。 LITE管理核心中的地址對映和許可權檢查，並嚮應用程式公開靈活的虛擬化記憶體抽象。 LITE僅在請求傳送方新增間接級別。 與原生RDMA一樣，使用LITE的單側RDMA操作不涉及任何遠端CPU，核心或LITE。 但是通過本地的間接層，LITE可以支援更靈活，透明，高效的記憶體區域管理和訪問控制。
4.1 LITE Memory Abstraction and Management
LITE的記憶體抽象基於LITE記憶體區域（LMR）的概念，LITE管理和暴露給應用程式的虛擬記憶體區域。 LMR可以是任意大小，並且可以對不同使用者具有不同的許可權。 在內部，LMR可以對映到一個或多個實體記憶體地址範圍。 LMR甚至可以分佈在不同的機器上。 這種靈活的物理位置對映可用於負載平衡需求。
LMR Handler。 LITE從使用者隱藏LMR的低階資訊（例如，其位置），並且僅暴露一個實體—LITE handler或lh。 lh可被視為LMR的一個功能[48,66]，它包含了許可權和地址對映。 LITE允許使用者為不同的使用者設定不同型別的許可權，例如read，write和master（我們很快會解釋master）。 在使用lh時，LITE提供了RDMA缺乏的透明度。 Native RDMA操作要求傳送方指定MR的目標節點，虛擬地址和rkey。 LITE隱藏了lh抽象背後的發件人的所有這些細節。 只有LMR的Master知道LMR所在的節點。 lh是使用者執行LITE操作所需的全部內容。 但是，沒有LITE，lh是沒有意義的，使用者不能使用lhs直接訪問本機MR。
我們讓使用者將他們自己的“名稱”與LMR相關聯，例如，DSM系統中的全域性記憶體地址或鍵值儲存系統中的鍵。 名稱在分散式應用程式中必須是唯一的。 其他使用者可以通過LT_map使用此名稱從LITE獲取LMR的lh。 這種命名機制為應用程式提供了充分的靈活性，可以在LITE的記憶體抽象之上強加他們選擇的任何語義。
Lh mapping and maintenance。 LITE管理從lh到其實體記憶體地址的對映，並在向RNIC發出Native RDMA操作之前對每個LMR執行許可權檢查。 LITE在訪問此LMR而不是LMR所在的節點上維護lh對映和許可權，因為我們希望避免遠端節點處的任何間接並保留RDMA的直接遠端訪問。 圖3顯示了使用和管理LMR的lhs的示例。
LMR的lh是節點上的本地程序; 它對其他程序或其他節點無效。 與允許使用者跨節點傳遞rkey和MR虛擬記憶體地址以訪問MR的Native RDMA不同，LITE可防止使用者直接傳遞lhs以提高安全性並簡化LMR的使用模型。 所有lh採集都必須使用LT_map進行LITE。 LITE總是為新的獲得產生新的lh。
Master role。 雖然LITE隱藏了LMR的大部分細節，例如其來自使用者的物理位置，但它將某些LMR管理功能開啟到稱為master的特殊角色。 建立LMR的使用者是其Master。 Master裝置可以選擇在LT_malloc期間分配LMR的節點。 我們還允許Master裝置將已分配的記憶體註冊為LMR。
Master可以將現有LMR移動到另一個節點。 Master維護已對映LMR的節點列表，以便當Master裝置移動或釋放（LT_free）LMR時，將通知這些節點處的LITE。 Master Role可以使用這些功能輕鬆執行資源管理和負載平衡。
只有主伺服器才能向其他使用者授予許可權。 為避免LMR的分配器成為效能瓶頸或單點故障，LITE支援多個LMR主機。 主角色可以向任何其他使用者授予Master許可權。
Non-Master map and unmap LMR。 想要首先訪問LMR的使用者需要通過向Master裝置使用LT_map來獲取lh。 在Master節點處，LITE檢查許可權並向請求節點回復LMR的位置。 然後，請求節點處的LITE生成新的lh並建立其對映和許可權。 LITE在請求節點儲存lh的所有元資料，以避免在使用者訪問LITE時掌握額外的RTT。 在LT_map之後，使用者可以使用lh和偏移量在表1中執行LITE Memory operator API。 要取消對映LMR，LITE將刪除使用者的lh及其所有關聯的元資料並通知Master節點。
Avoiding RNIC indirection。 利用LITE管理LMR的地址對映和許可權檢查，我們希望在RNIC中刪除冗餘間接並減少其記憶體壓力。 但是，在不更改硬體的情況下，LITE只能使用真實MR執行Native RDMA操作，這些MR在RNIC中進行對映和保護。
幸運的是，RDMA Verbs支援不常用的API - 核心空間可以使用實體記憶體地址直接向RNIC註冊MR。 LITE利用此API僅註冊一個覆蓋整個物理主存的RNIC。 使用這種Global MR可以提供多種好處。
首先，它消除了RNIC獲取或快取PTE的需要。 對於Native RDMA，RNIC需要在執行DMA操作之前使用其PTE將使用者級虛擬記憶體地址對映到物理虛擬記憶體地址。 由於LITE使用實體記憶體地址註冊全域性MR，因此RNIC可以直接使用實體地址而無需任何PTE。 這種技術在很大程度上提高了LITE的LMR尺寸效能可擴充套件性（§4.2）。
其次，對於全域性MR，LITE僅使用RNIC註冊一個lkey和一個rkey，並使用全域性lkey和rkey向RNIC發出所有RDMA操作。 由於RNIC只有一個全域性lkey和rkey，因此LITE在LMR數量方面沒有可擴充套件性問題（第4.2節）。
最後，使用實體地址的一個微妙的影響是避免在建立LMR期間昂貴的儲存器釘扎過程。 建立MR時，Native RDMA會遍歷其所有記憶體頁並將它們固定在主記憶體中，以防止它們在RDMA操作期間被換出[47,56]。 相比之下，LITE不需要經歷這個過程，因為它為LMR分配實體記憶體區域。
但是，使用實體地址向RNIC註冊全域性MR有一個潛在的問題。 LITE必須使用實體記憶體地址向RNIC發出RDMA操作，並且RDMA操作中的記憶體區域需要物理連續。這兩個約束意味著每個LMR也必須是物理上連續的。但是，分配大的物理連續記憶體區域可能會導致外部碎片。
為了解決這個問題，我們利用LMR間接的靈活性，並將大型LMR擴充套件到更小的物理連續儲存區域。當用戶對這樣的LMR執行LITE讀或寫操作時，LITE將在不同的物理儲存器區域發出若干RDMA操作。在我們的實驗中，與在巨大的物理連續區域（例如，128 MB）上執行RDMA操作相比，該技術可以很好地擴充套件並且僅具有小於2％的效能開銷，而後者將導致外部碎片。當LMR很小時，LITE仍然只分配一個連續的實體記憶體。
4.2 LITE RDMA Benefits and Performance
LITE通過在執行地址轉換和許可權檢查後發出Native單邊RDMA讀取或寫入RNIC來執行單向LT_read和LT_write。 由於LITE直接使用實體記憶體地址來執行本機RDMA操作，因此不需要任何記憶體副本，LITE保留RDMA的零拷貝優勢。 LITE允許請求的應用程式執行緒執行到最後並且不會產生排程成本。 與Native RDMA READ/WRITE不同，LT_read和LT_write僅在資料已成功讀取或寫入時返回。 因此使用者無需單獨輪詢完成狀態。 LITE的單邊RDMA實現了多項優勢。
首先，LITE的記憶體抽象允許LMR的物理位置，命名和許可權具有更大的靈活性。 LMR間接還增加了高度的透明度，但仍然讓主裝置執行記憶體資源管理和負載平衡。
其次，與以前的解決方案[19]不同，LITE不需要對RDMA驅動程式或作業系統進行任何更改，而是完全在可載入的核心模組中實現。
最後，LITE解決了§2.4中原生RDMA的效能可擴充套件性問題，同時在規模較小時仍能提供接近原始的RDMA效能。 我們希望資料中心環境具有大規模，使得LITE比原生RDMA具有更好的效能選擇。
圖4顯示了隨著LMR或MR數量的增加，LT_write和本機RDMA寫入的延遲。圖5顯示了隨著LMR或MR的大小增加，LT_write和本機RDMA寫入的吞吐量。讀取效能有類似的結果。原始RDMA的效能隨著MR的數量和大小而迅速下降，而LITE在LMR的數量和LMR的總大小方面都很好地擴充套件，並且當規模很大時優於原生RDMA。
圖6和圖7詳細介紹了LITE，本機RDMA寫入和TCP / IP的延遲和吞吐量比較。我們使用qperf [23]來測量InfiniBand上的TCP / IP效能（通過IPoIB）。即使規模較小，LITE的效能也很接近，有時甚至比原生RDMA更好。 LITE的核心級RDMA效能幾乎與原生RDMA相同，其使用者級RDMA僅比原生RDMA略微增加。使用更多執行緒，LITE的吞吐量略好於原生RDMA。 TCP / IP的延遲始終高於本機RDMA和LITE，並且TCP / IP的吞吐量大多低於它們。當請求大小介於128 B和1 KB之間時，TCP / IP的吞吐量略高於RDMA，因為qperf以非阻塞方式執行請求，而我們的RDMA實驗以阻塞方式執行。=
如圖8所示，LITE的LMR暫存器和取消註冊過程在MR大小方面也比原始RDMA快得多，並且擴充套件得更好。如本節前面所述，本機RDMA引腳（取消）主要MR的每個儲存器頁面註冊（取消註冊）期間的記憶體，而LITE避免了這個昂貴的過程。
5. LITE RPC
上一節描述了表1中LITE的記憶體抽象和類似記憶體的基本操作。除了單面RDMA和類似記憶體的操作外，LITE仍然支援傳統的雙面訊息傳遞。 但我們關注的主要型別的雙面操作是RPC。 本節討論LITE的RPC實現和評估（表1的第二部分）。
我們相信RPC在許多分散式應用程式中很有用，例如，實現分散式協議，執行遠端功能，或者只是傳送訊息並獲得回覆。 我們提出了一種新的基於RDMA的雙向RPC機制和一組優化技術，以降低RPC期間核心交叉的成本。 LITE RPC介面類似於傳統的RPC [9]。 每個RPC函式都與多個RPC客戶端可以繫結的ID相關聯，並且多個RPC伺服器執行緒可以執行。
5.1 LITE RPC Mechanism
RDMA-write-imm-based Communication。 我們提出了一種構建基於RDMA的RPC通訊的新方法：使用兩個RDMA write-imm操作。 Write-imm是一個類似於RDMA WRITE的Verbs。 但是除了執行直接寫入遠端儲存器之外，它還發送32位立即（IMM）值，並通過在遠端節點的接收CQ中放置IMM條目來通知遠端CPU完成WRITE。
LITE執行一個write-imm用於傳送RPC呼叫輸入，另一個write-imm用於傳送回覆。 LITE在LMR中寫入RPC輸入和輸出，並使用32位IMM值傳遞某些內部元資料。 為了實現低延遲和低CPU利用率，LITE使用一個共享輪詢執行緒來忙於輪詢所有RPC請求的全域性接收CQ。 LITE定期在後臺Post接收佇列中的IMM緩衝區
LITE RPC Process。 當RPC客戶端節點首次請求與RPC函式繫結時，LITE在RPC伺服器節點上分配新的內部LMR（例如，16 MB）。 標頭指標和尾指標指示此LMR中的已用空間。 客戶機節點寫入LMR並管理尾指標，而伺服器節點從LMR讀取並管理標頭指標。
圖9說明了LT_RPC呼叫的過程。 RPC客戶端使用函式輸入呼叫LT_RPC，併為返回值1呼叫記憶體空間地址。 LITE使用write-imm將輸入資料和返回儲存器空間的地址寫入伺服器節點2處的LMR的尾指標位置。 LITE使用IMM值來包含RPC函式ID和資料在LMR中開始的偏移量。
在伺服器節點，使用者執行緒呼叫LT_recv RPC以接收下一個RPC呼叫請求。 當伺服器節點輪詢來自CQ的新接收請求時，它解析IMM值以獲得相應LMR 3中的RPC功能ID和資料偏移。 LITE將資料從LMR移動到LT_recv RPC呼叫中指定的使用者儲存空間，並返回LT_recv RPC呼叫4。 此時調整LMR頭指標，另一個後臺執行緒將新的頭指標傳送到客戶端節點f。 RPC伺服器執行緒在4之後執行RPC函式，並使用函式返回值5呼叫LT_reply RPC。 LITE使用write-imm 6將此值寫入LT_RPC中指定的地址的客戶機節點。 客戶端節點LITE在輪詢寫入7的完成時返回LT_RPC呼叫8。
為了提高LT_RPC吞吐量並降低CPU利用率，我們不會輪詢任何write-imm的傳送狀態。 LITE依賴於RPC reply（7）來檢測RPC程序中的任何失敗，包括write-imm錯誤; 如果LITE在一段時間內沒有收到回覆，則會向用戶返回超時錯誤。 因此，我們可以安全地刪除傳送狀態的檢查。
5.2 Optimizations between User-Space and Kernel
上述LITE RPC過程的直接實現將涉及三個系統呼叫開銷（LT_RPC，LT_recv RPC和LT_reply RPC）和六個使用者核心空間交叉，成本約為0.9μs。 我們提出了一組優化技術來減少LITE RPC的開銷。 由此產生的RPC過程僅產生兩個使用者到核心的交叉點15，或者在我們的實驗中大約0.17μs。
LITE通過從效能關鍵路徑中刪除此核心到使用者的交叉來隱藏將系統呼叫從核心空間返回到使用者空間的成本。 當LITE收到LT_RPC或LT_recv RPC系統呼叫時，它立即返回使用者空間而不等待結果b d。 但是LITE不是將執行緒返回給使用者，而是將其返回給LITE使用者級庫。
我們使用在核心和應用程式程序之間共享的小記憶體空間（一頁）來指示系統呼叫結果的就緒狀態，類似於之前輕量級系統呼叫中使用的共享記憶體空間[13,73] ]。當LITE使用者級庫發現系統呼叫的結果準備就緒時，它將系統呼叫返回給使用者4 8。
為了進一步提高吞吐量，我們提供了一個可選的LITE API來發送回復並等待下一個收到的請求。此API結合了LT_reply RPC和LT_recv RPC，以便刪除步驟a和b。此介面對於連續接收RPC請求的RPC伺服器非常有用。
執行上述優化時，LITE可最大限度地降低CPU利用率。與先前需要多個核心執行緒以減少系統呼叫開銷[73]或需要更改系統呼叫介面[29,73]的解決方案不同，LITE不需要任何其他核心（或使用者級）執行緒或任何介面更改。此外，LITE庫使用自適應方式來管理執行緒。它首先嚐試忙於檢查共享狀態。如果它很快沒有得到任何就緒狀態，LITE庫將使使用者執行緒進入休眠狀態並懶惰地檢查就緒狀態（c e）。
除了最小化系統呼叫開銷之外，LITE還最大限度地降低了使用者和核心空間之間的記憶體複製成本。 LITE通過使用其實體地址直接定址使用者級記憶體緩衝區來避免幾乎所有的記憶體複製（1 5 8）。 LITE僅移動一個記憶體以將資料從伺服器節點處的LMR移動到使用者指定的接收緩衝區。從我們的實驗結果來看，這樣做可以通過儘快釋放內部LMR空間來大大提高RPC吞吐量。
5.3 LITE RPC Performance and CPU Utilization
LITE提供了一個支援不同應用程式的RPC操作的通用層。 LITE RPC提供低延遲，高吞吐量，可擴充套件的效能，高效的記憶體使用和低CPU利用率。 圖10和圖11展示了LT_RPC的延遲和吞吐量以及它們與其他系統的比較方式。
使用者級LT_RPC在核心級別上只有非常小的開銷。 為了進一步瞭解LITE RPC的效能影響，我們分解了一個LITE RPC呼叫的總延遲。 在傳送8B金鑰和在LT_RPC呼叫中返回4 KB頁面所花費的總6.95μs中，包括對映和保護檢查在內的元資料處理花費的時間少於0.3μs。 LT_recvRPC和LT_replyRPC的核心軟體堆疊分別需要0.3μs和0.2μs。 使用者核心空間交叉的成本為0.17μs。
為了將LITE與相關工作進行比較，我們在數量上和質量上將其與幾個現有的基於RDMA的系統及其RPC實現進行了比較。 FaRM [19]使用RDMA write作為其訊息傳遞機制。 RPC可以在FaRM之上實現，具有兩個RDMA寫入。 由於FaRM不是開源的，我們直接將LITE的RPC延遲與兩個本機RDMA寫入延遲的總和進行比較，這是一個下限但不足以構建真正的RPC操作。 LITE與兩個本機RDMA寫入相比只有輕微的開銷。
接下來，我們使用他們的開源實現將LITE與兩個開源的基於RDMA的RPC系統HERD [38]和FaSST [39]進行比較。 HERD使用針對RPC呼叫的單側RDMA寫入和針對RPC返回的一個UD傳送來實現RPC。 HERD的RPC伺服器執行緒忙於檢查RDMA區域以瞭解新的RPC請求何時到達。 相比之下，LITE使用write-imm並輪詢IMM值以接收RPC請求。 檢查一個RDMA區域的延遲比LITE基於IMM的輪詢略快（如圖10中的微基準測試結果）。 但是，實際上，HERD的機制不適用於我們為資料中心應用程式提供服務的目的，因為它需要忙於檢查所有RPC客戶端的不同RDMA區域，從而導致高CPU或效能開銷。 LITE僅檢查一個接收CQ，其中包含所有RPC客戶端的IMM值。
FaSST是另一個使用兩個UD傳送的RPC實現。 當RPC大小較大時，LITE具有比FaSST更好的吞吐量和更好的延遲。 FaSST使用主執行緒（稱為協程）來輪詢接收CQ以獲取傳入的RPC請求並執行RPC功能。 我們的評估使用FaSST的基準測試，該基準測試執行虛擬零長度RPC功能。 實際上，在輪詢執行緒中執行任意RPC函式是不安全的，並且會導致吞吐量瓶頸。 LITE允許使用者執行緒執行RPC函式並確保輪詢執行緒是輕量級的。
此外，LITE比基於傳送的RPC實現更節省空間。 要使用send，接收節點需要預先發布足夠大的接收緩衝區以容納所有RPC資料的最大大小，從而導致大量浪費的記憶體空間[72]。 相比之下，對於write-imm，LITE不需要任何RPC資料的接收緩衝區。 圖12顯示了使用LITE RPC的記憶體空間利用率，並在Facebook鍵值儲存分佈下發送[3]。 相比之下，對於基於傳送的RPC，我們已經使用了一種記憶體空間優化技術，該技術可以在不同的RQ上釋出不同大小的接收緩衝區，並選擇最節省空間的RQ來將資料傳送到[72]。 儘管如此，LITE比基於傳送的RPC顯著更節省空間，特別是對於傳送大資料（Facebook鍵值儲存工作負載中的值）。
最後，我們評估LITE的CPU利用率，並將其與HERD和FaSST進行比較。 我們首先使用一個簡單的工作負載，即每秒使用8個執行緒在兩個節點之間傳送1000個RPC請求。 LITE的總CPU時間為4.3秒，而HERD和FaSST使用8.7秒和8.8秒。
然後，我們實現了一個巨集基準測試，它使用Facebook鍵值儲存分佈[3]執行具有到達間隔時間，輸入和返回值大小的RPC呼叫。 為了評估不同負載下的CPU利用率，我們將原始分佈的到達間隔時間乘以1倍到8倍。 圖13繪製了執行100,000次RPC呼叫時每次請求的LITE，HERD和FaSST的平均CPU時間。 當工作負載較輕時（即較大的到達間隔時間），LITE使用的CPU比HERD和FaSST都少，主要是因為LITE的自適應執行緒模型讓執行緒休眠。 當工作負載很重時，LITE的CPU利用率優於FaSST，類似於HERD。
6. RESOURCE SHARING AND QOS
本節討論LITE如何在不同應用程式之間共享資源並保證服務質量（QoS）。 我們的重點是展示使用LITE共享資源和執行QoS的可能性和靈活性，但不是為了找到資源共享或QoS的最佳策略。
6.1 Resource Sharing
LITE在使用者應用程式之間以及LITE的單邊RDMA和RPC元件之間共享許多型別的資源。 總的來說，LITE使用K×N QP和一個忙輪詢執行緒用於每個節點的共享接收CQ，其中N是節點的總數。 K是控制總系統頻寬和QP總數之間權衡的可配置因子; 從我們的實驗中，1≤K≤4可以獲得最佳效能。 能夠共享資源在很大程度上提高了LITE的可擴充套件性並最大限度地減輕了硬體負擔。 相比之下，Verbs上的非共享實現需要2×N×T QP，其中T是每個節點的執行緒數。 FaRM [19]在一個應用程式中共享QP並需要2×N×T / q QP，其中q是共享因子。 FaSST [39]使用T UD QP; UD不可靠，不支援單面RDMA操作。 這些方案中沒有一個在應用程式之間共享QP或輪詢執行緒。 圖14顯示LITE單側RDMA和LT_RPC都可以很好地擴充套件節點數
6.2 Resource Isolation and QoS
在共享資源時，LITE可確保使用者資料得到正確保護，並確保不同使用者的效能相互隔離。我們探索了兩種交付QoS的方法。第一種方式（HW-Sep）依靠硬體資源隔離來實現QoS。具體而言，HW-Sep針對不同的優先順序保留不同的QP和CQ，例如，針對高優先順序請求的三個QP和針對低優先順序請求的一個QP。特定優先順序下的作業只能使用為該優先順序保留的資源。
第二種方法（SW-Pri）使用三種軟體策略的組合在傳送方執行基於優先順序的流量和擁塞控制：1）當高優先順序作業的負載高時，速率限制低優先順序作業（即，降低傳送速度）; 2）當沒有或非常輕的高優先順序工作時，不要對低優先順序工作進行速率限制; 3）當高優先順序作業的RTT增加時，速率限制低優先順序作業。我們選擇這三個策略來證明使用LITE實現各種流量控制策略簡單靈活;前兩個策略基於傳送方資訊，最後一個策略利用接收方資訊。
我們首先使用合成工作負載評估HW-Sep和SW-Pri，這些工作負載混合了執行不同請求大小的LT_write和LT_read的高優先順序和低優先順序作業。圖16詳述了此工作負載，並繪製了HW-Sep，SW-Pri的效能，並且隨著時間的推移沒有QoS。可以預見，如果沒有QoS，高優先順序作業只能使用與低優先順序作業相同的資源量，因此只能實現總頻寬的一半。 SW-Pri實現了高聚合頻寬，接近“無QoS”結果，同時能夠保證高優先順序作業的卓越效能。 HW-Sep的QoS比SW-Pri差，其綜合性能是三者中最差的。這是因為即使沒有高優先順序的作業，低優先順序作業也無法使用HW-Sep為高優先順序作業預留的資源，從而限制了HW-Sep可實現的總頻寬。這一結果表明純粹的基於硬體的QoS機制（HW-Sep）無法提供像SW-Pri這樣的軟體機制提供的靈活性和效能。
接下來，我們用實際應用程式評估了LITE的QoS。我們運行了兩個我們構建的應用程式，LITE-Graph（§8.3）和LITE-Log（§8.1），具有高優先順序，以及一個低優先順序的後臺任務，即不斷地將資料寫入 四個節點。 圖15比較了HW-Sep，SW-Pri和無QoS下的LITE-Graph和LITE-Log的效能。 與我們對合成工作負載的研究結果類似，SW-Pri在實際應用中也比HW-Sep實現更好的QoS。 與LITE-Log相比，LITE-Graph受QoS影響較小，因為它比LITE-Log更加CPU密集。
7. EXTENDED FUNCTIONALITIES
本節介紹了我們在LITE的RDMA和RPC堆疊之上構建的LITE擴充套件功能的實現和評估。 這些功能包括我們未在§4（表1的其餘儲存器部分）和同步操作（表1的同步部分）中介紹的類似儲存器的操作。
7.1 Memory-Like Operations
除了RDMA讀寫之外，LITE還支援一組豐富的類似記憶體的API，這些API具有與傳統單節點記憶體操作類似的介面，包括記憶體（de）分配，設定，複製和移動。 為了最大限度地減少網路流量，LITE在內部使用其RPC介面來實現大多數LITE記憶體API。 圖17顯示了隨著LMR大小的增長，LT_malloc，LT_memset，LT_memcpy和LT_memmove（表1）的延遲。
應用程式使用lhs呼叫這些類似記憶體的API，其方式與使用虛擬記憶體地址呼叫POSIX記憶體API的方式類似。 例如，應用程式指定源lh和目標lh以執行LT_memcpy和LT_memmove。 LITE通過將LT_RPC傳送到儲存源LMR的節點來實現LT_memcpy和LT_memmove。 如果目標LMR位於同一節點，則此節點將執行本地memcpy或memmov。 否則，它