一周一论文（翻译总结）—— [SOSP 18] LITE Kernel RDMA Support for Datacenter Applications : 一个LITE 内核支持的RDMA通信库

浅浅的花香味﹌ 2022-04-16 00:28 227阅读 0赞

**目录**

Abstract

1. Introduction

2. BACKGROUND AND ISSUES OF RDMA

2.1 Background on 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

3.1 Kernel-Level Indirection

3.2 Challenges

3.3 LITE Overall Architecture

3.4 LITE Design Principles

4. LITE MEMORY ABSTRACTION AND RDMA

4.1 LITE Memory Abstraction and Management

4.2 LITE RDMA Benefits and Performance

5. LITE RPC

5.1 LITE RPC Mechanism

5.2 Optimizations between User-Space and Kernel

5.3 LITE RPC Performance and CPU Utilization

6. RESOURCE SHARING AND QOS

6.1 Resource Sharing

6.2 Resource Isolation and QoS

7. EXTENDED FUNCTIONALITIES

7.1 Memory-Like Operations

7.2 Synchronization and Atomic Primitives

8. LITE APPLICATIONS

8.1 Distributed Atomic Logging

8.2 MapReduce

8.3 Graph Engine

9. RELATEDWORK

10. CONCLUSION

--------------------

## 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的体系结构。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70][]

首先，我们仅在本地节点添加一个间接级别，并且仍然确保单边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。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 1][]

在内部，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的示例。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 2][]

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。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 3][]

图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避免了这个昂贵的过程。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 4][]

## 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中开始的偏移量。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 5][]

在服务器节点，用户线程调用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的延迟和吞吐量以及它们与其他系统的比较方式。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 6][]

用户级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。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 7][]

为了将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这样的软件机制提供的灵活性和性能。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 8][]

接下来，我们用实际应用程序评估了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密集。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 9][]

## 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。 否则，它将对位于不同节点的目标LMR执行LT\_write。 然后，该节点将回复请求节点，完成应用程序调用。

LITE通过向存储LMR的远程节点发送命令来实现LT\_memset，该LMR执行本地memset并进行回复。 实现LT\_memset的另一种方法是使用要设置的值对MR执行LT\_write。 当LMR大小增加时，这种替代方法比我们实现LT\_memset更糟糕，因为它通过网络发送更多数据。

### 7.2 Synchronization and Atomic Primitives ###

LITE提供一组同步和原子初始值，包括LT\_lock，LT\_unlock，LT\_barrier，LT\_fetch-add和LT\_test-set（表1）。最后两个是他们相应的原生动词的直接包装。我们添加了分布式锁定和分布式屏障接口，以帮助LITE用户执行分布式协调。

我们使用LITE锁定的有效实现来平衡锁定操作延迟和网络流量开销。 LITE锁只是内部LMR中的64位整数值，每个锁都有一个所有者节点。 LT\_lock操作首先使用一个LT\_fetch-add来尝试获取锁。如果锁定可用，则此采集过程非常快（在我们的实验中为2.2μs）。否则，LITE将向锁的所有者发送LT\_RPC，该锁保持等待锁的所有用户的FIFO队列。通过维护FIFO等待队列，LITE只需唤醒并在锁定可用后向一个等待用户授予锁定，从而最大限度地减少网络流量。我们的实验表明，LITE锁定可以很好地匹配竞争线程和节点的数量。

## 8. LITE APPLICATIONS ##

为了展示LITE的易用性，灵活性和卓越性能，我们在LITE上开发了四个数据中心应用程序。 本节介绍如何构建或移植这些应用程序及其性能评估结果。 我们总结了本节末尾在LITE上构建应用程序的经验。

### 8.1 Distributed Atomic Logging ###

LITE-Log是一个简单的分布式原子日志系统，我们使用LITE的内存API构建。通过LITE-Log，我们将“片面”概念推向极致：全局日志的创建，维护和访问都是从远程执行的。这种片面LITE-Log对用户完全透明，使用起来非常简单。

分配器使用LT\_malloc将全局日志创建为LMR，将多个元数据变量创建为LMR。一组写入器将事务提交到日志，日志清理器定期清除日志。同一节点可以运行多个角色。

写入日志（日志条目）在本地节点缓冲，直到提交时间。在提交时，编写器首先通过使用LT\_fetch-add测试和调整日志的元数据，在日志中为其事务数据保留连续的空间。然后，编写器将具有LT\_write的事务写入保留的日志空间。日志清理程序在后台运行，以在LT\_read，LT\_fetch-add和LT\_test-set的帮助下清理全局日志。

我们的实验表明，当两个节点同时提交单项（16B）事务和LITE-Log的事务提交吞吐量随节点数和事务大小而变化时，LITE-Log每秒可实现833K事务提交。

### 8.2 MapReduce ###

LITE-MR是我们在LITE上实现的MapReduce \[18\]。 我们从Phoenix \[65\]移植了LITE-MR，它是MapReduce的单节点多线程实现。 我们将原始的Phoenix映射器和缩减器线程分散到一组工作节点上，并使用单独的节点作为主节点。 主服务器强制执行原始的Phoenix作业拆分策略，但将任务拆分为多个工作节点。 我们使用LT\_read和LT\_RPC实现了LITE-MR的网络通信。

与MapReduce相同，LITE-MR使用三个阶段：map，reduce和merge。在映射阶段，每个工作线程执行主服务器分配的映射任务。完成所有映射任务后，工作线程将所有中间结果组合成一组已完成的缓冲区。然后，它为每个已确定的缓冲区注册一个带有标识符的LMR，并将所有标识符发送给主服务器。

在reduce阶段，master将映射阶段收集的标识符发送给reduce工作线程。工作线程使用这些标识符使用LT\_read直接从映射器节点读取映射结果。在完成所有reduce任务之后，reduce工作线程会合并其所有任务的结果。它将组合缓冲区注册到一个LMR，并将其关联的标识符报告给主站。合并阶段的工作方式与缩减阶段相似;每个合并工作线程读取使用LT\_read减少结果。在合并阶段结束时，主节点使用LT\_read读取最终结果并将结果报告给用户。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 10][]

图18显示了使用Phoenix，LITE-MR和Hadoop \[1\]的维基媒体工作负载\[79\]的WordCount运行时间。对于所有方案，我们使用相同数量的总线程。 Phoenix使用单个节点，而LITE-MR和Hadoop使用2个，4个和8个节点。 LITE-MR的性能优于Hadoop 4.3倍至5.3倍。我们在IPoIB上运行Hadoop，它的性能比LITE的RDMA堆栈差得多。

令人惊讶的是，使用相同数量的总线程数，LITE-MR也优于Phoenix，即使LITE涉及网络通信且Phoenix仅访问单个节点上的共享内存。我们将Phoenix和LITE-MR的运行时间分解为不同的阶段，发现LITE-MR的映射和减少阶段比Phoenix更短。在这些阶段中，只有reducer从映射器中读取数据。我们做了一个简单的更改，将Phoenix的全局树结构索引修改为每个节点的索引，以便在分布式节点上运行LITE-MR。此变化的收益大于LITE中的网络通信成本。但是，在Phoenix中使用相同的拆分索引会影响Phoenix对本地线程的多核优化。 LITE-MR的合并阶段比Phoenix更糟糕，因为要合并的所有数据都在Phoenix的单个节点上，而它们位于具有LITE-MR的不同节点上。 LITE-MR和Phoenix都使用双向合并，需要多轮读写数据。但是，此成本是执行分布式合并的结果，而不是因为使用LITE。最后，LITE-MR在更多节点上表现更好，因为LMR的总数保持不变，但映射和取消映射LMR的成本在更多节点上摊销。

### 8.3 Graph Engine ###

我们基于PowerGraph \[25\]的设计实现了一个新的图形引擎LITE-Graph。与PowerGraph一样，它使用以顶点为中心的表示来组织图形。它将全局图数据存储在一组LMR中，并将图处理负载分配给LITE节点上的多个线程。每个线程在三个步骤中对一组顶点执行图算法：收集，应用和散布，以及delta缓存的优化\[25\]。

在每个步骤之后，我们执行LT\_barrier以仅在所有LITE节点完成上一步骤时开始下一步骤。在散布步骤中，LITE-Graph使用LT\_read和LT\_write来读取和更新存储在LMR中的全局数据。为了确保全局数据的一致性，我们一次只能允许一次写入。 LITE-Graph使用LT\_lock来保护每个LMR的更新。通过此实现，将全局数据拆分为更多LMR可以增加并行性和LITE-Graph的总吞吐量。

我们使用LITE-Graph，Power-Graph和Grappa \[59\]在Twitter数据集（1M顶点，1 B有向边）\[43\]上执行PageRank \[45\]。 Grappa是一个DSM系统，它使用基于IB的定制网络堆栈来聚合网络请求。 PowerGraph在InfiniBand上使用IPoIB。图19显示了使用四个节点和七个节点的这些系统的总运行时间，每个节点运行四个线程。与PowerGraph和Grappa相比，LITE-Graph表现更好，主要是由于LITE的堆栈优于IPoIB和Grappa的网络堆栈的性能优势。

## 9. RELATEDWORK ##

在过去几年中，为数据中心环境构建了几个基于RDMA的新系统。 FaRM \[19\]是一个基于RDMA的分布式存储平台，它启发了LITE。 其核心通信堆栈使用RDMA读写。 在基本通信堆栈之上，FaRM构建了一个分布式共享内存层，一个事务系统\[20\]和一个分布式哈希表。 LITE-DSM也是一个分布式共享内存层，但LITE更加通用和灵活：它支持其他类型的远程内存使用和基于write-imm的RPC机制; 它安全地跨应用程序共享资源; 它不需要大页面或任何驱动器更改。

Pilaf \[58\]和HERD \[37\]是两个使用RDMA读，写或发送实现定制RDMA堆栈的键值存储系统。 HERD-RPC \[38\]和FaSST \[39\]是两个基于RDMA的RPC实现。 FaSST的主要目标是扩展节点数量。 Derecho项目\[4,7,8\]是建立分布式计算环境的一系列努力。 它使用基于newRDMA的多播机制和共享状态表来实现多个共识和成员协议。 还有一些基于RDMA的数据库和事务系统\[6,11,20,78,81\]，分布式RDF存储\[70\]，DSM系统\[59\]，共识系统\[77\]和分布式NVM系统\[52\] ，69,82\]。 这些系统都针对特定类型的应用程序，并且大多数都构建定制软件以使用RDMA。 LITE是一个通用的共享间接层，支持各种数据中心应用程序。 构建LITE具有独特的挑战，其设计决策无法仅针对一个应用程序进行定制。

有几个基于RDMA的用户级库，包括标准OFED库\[62\]，rdma-cm \[35\]，MVA-PICH2 \[32,51\]，Rsockets \[30\]和Portals \[10\]。 MVAPICH2支持MPI接口，专为HPC环境而设计。 Rsockets实现类似套接字的抽象。 门户网站公开了一个基于put和get操作的抽象。 LITE的抽象是为数据中心应用程序设计的，比这些库的抽象更丰富，更灵活。 此外，LITE使用内核级间接来解决数据中心中的本机RDMA问题，这些问题都不会解决。 在IP之上还有几个内核级层，例如IPoIB，SDP \[24\]和SRP \[74\]，以支持传统的网络和存储接口。 它们都具有很高的性能开销，并且不像LITE那样提供低延迟性能。

最后，在用户级TCP / IP实现方面已经进行了各种努力，例如mTCP \[36\]，U-Net \[76\]，IX \[5\]和Arrakis \[63\]。将TCP / IP堆栈从内核移动到用户空间可以降低内核交叉的性能成本。但是，跨用户级进程的资源共享效率低且不安全。实际上，U-Net和IX依靠内核来执行资源隔离。硬件强制隔离机制（如SR-IOV）是让用户级进程安全访问硬件资源的一种方法，并且已被Arrakis等系统使用。但是，与TCP / IP不同，硬件隔离机制限制了RDMA的灵活性，因为这些机制需要为DMA分配和固定每个应用程序（或VM）的所有内存\[64\]。像LITE这样的内核中的软件层可以按需分配和映射应用程序内存，即仅在访问时。软件还可以实现更灵活的资源共享和隔离策略。此外，LITE专为RDMA设计，可解决数据中心环境中的RDMA问题。

## 10. CONCLUSION ##

我们在操作系统中展示了LITE，一个本地间接TiEr，用于虚拟化和管理数据中心应用程序的RDMA。 在数据中心环境中使用时，LITE解决了本机RDMA的三个关键问题：抽象不匹配，性能不可靠以及缺乏资源管理。 LITE演示了使用内核级间接层可以在解决问题的同时保留原生RDMA的良好性能。 我们对LITE进行了广泛的评估，并在LITE上构建了四个数据中心应用程序。 总的来说，LITE既易于使用又表现良好。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70]: /images/20220416/963bf91846574a2c8937b104501652cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 1]: /images/20220416/54a2a8f20cc64977afe82bf705ce316c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 2]: /images/20220416/c9c0bbb01d494a9589be8eed6fd88bc1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 3]: /images/20220416/a3794f478b00430cbfa35ea0739023a1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 4]: /images/20220416/a2dd6fd4ac144964a74b0ef43cc6ceec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 5]: /images/20220416/b0f21134ebc445eaa9e5b772a28f6d8a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 6]: /images/20220416/c5058cfc340a4e9aa8bb6d1252fda407.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 7]: /images/20220416/f531d061bd9d4772ac5d6040f2c91a28.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 8]: /images/20220416/fee2a347d3884f01b70f48918f397563.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 9]: /images/20220416/964e3c0993d4441dae38bb2989850d43.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMTI1MTgz_size_16_color_FFFFFF_t_70 10]: /images/20220416/9b05c023a4cb4c06a9cc3b59f7cecbe8.png