软硬件协同的远端内存系统研究①

李海锋 刘 珂 陈明宇

(*中国科学院计算技术研究所 北京 100190)

(**中国科学院大学 北京 100049)

0 引言

虚拟内存子系统(virtual memory system,VMS)一直是操作系统(operate system,OS)的重要组成部分,它作为中间层使用户可以创建并访问大量的虚拟内存空间。如今,VMS 在基于微秒级网络的远端内存系统中发挥着至关重要的作用。例如,云服务供应商利用VMS 将冷页面,即不常用的页面,透明地交换到廉价的慢速存储设备当中,以节省内存成本[1-2];基于内核的远端内存系统与VMS 紧密结合在一起,从而实现远端内存的访问[3-5]。此外,随着新兴内存(如持久内存[6])与互连内存(如新的计算互连标准[7-8])的出现,基于多层内存的系统利用VMS 进行数据迁移或交换。

这些系统通常依赖于3 种核心VMS 机制:(1)请求分页,即系统拦截内存访问,然后从慢速设备(如远端内存)读取页面,将其缓存在本地内存中;(2)页面交换,即系统将本地页面替换到慢速设备为其他进程腾出空闲内存;(3)页面预取,即系统预测未来页面使用情况,并在进程使用页面之前从慢速设备中读取页面到本地内存。

然而,现有的VMS 数据路径存在高昂的开销,这是因为其使用了粗粒度的锁,且在关键路径上存在同步的函数调用。尽管一些工作在努力优化数据路径,但它们都没有办法解决这些根本问题[9]。因此,先前的工作专注于通过优化页面预取和收回算法,来降低应用在关键路径上访问远端的次数,从而尽可能减少关键数据路径的开销[5,9]。然而,这种方式仍然存在不足,其优势被第2 个限制所抵消,即页面预取和回收无法精确地确定要预取与回收的页面。这是因为它们只能用有限的访问信息来训练算法。为了让操作系统获取更加完整的访问信息,一种可能的解决方法是使用守护进程定期扫描页表中的访问位,以近似显示用户访问历史[1]。但是,这种方法不仅会造成由于地址转换后援缓冲器击落和固定扫描线程而带来的开销,而且产生的访问信息不是实时的,是粗粒度且高延迟的。

这种限制源于操作系统和硬件之间存在语义鸿沟:处理器仅能通过页表向操作系统传递粗粒度和陈旧的访问信息,因此操作系统对其运行的应用程序的内存访问信息了解有限,必须使用高开销的软件方法来近似获取应用程序访问信息。本文认为,源自内存层次结构中较高层的丰富访问历史记录可以使较低层构更好地分析内存访问模式,从而建立更好的驱逐或预取模型。例如,如果操作系统知道关键的最后一级缓存缺失信息,则OS 可以构建精确的替换和预取模型。

因此,本文提出通过内存控制器(memory controller,MC)捕获应用实时访存信息,并将它们高效且实时地提供给操作系统。这样,VMS 获得了足够的实时内存访问信息,就可以改进其页面替换和预取算法。具体来说,本文在内存控制器中部署了热点页面提取表。热点页面提取表分析缓存块粒度的访存请求并生成页粒度的访存请求。反向页表通过软件的方式进行构建,负责将物理页面翻译为虚页面和进程号。

本文构建了2 个样例来展示软硬件协同框架带来的好处。首先,改进了谷歌发布的远端内存系统[3],将其默认的顺序预取策略替换为软硬件协同框架支持的基于流的预取算法。其次,本文改进了默认的内核替换算法,将其基于访问位的替换算法改为软硬件协同框架支持的替换算法。除了本文提供的使用样例,其他场景也可以使用软硬件协同框架所提供的访存信息进行优化。例如,用户可以使用这些信息指导页面的迁移等。

由于MC 无法直接修改,本文在x86 服务器上构建了一个原型仿真系统,用于验证和评估。本文利用了基于硬件的内存跟踪工具HMTT (hybrid memory trace tool)[10-11],同时在用户空间中构建处理访存信息的软件。本文认为新增的硬件设计是轻量级和通用的,因此可以轻松集成到中央处理器(central processing unit,CPU)芯片或各种CPU 平台的MC。

本文使用许多大规模内存应用程序来评估软硬件协同框架和这2 个用例。总体而言,软硬件协同框架有助于实质性地改进基于VMS 的系统。例如,当应用程序的一半内存被分配到远端时,软硬件协同框架驱动的预取器将基于谷歌的远端内存系统的应用性能提高59%,同时,预取器的精度和覆盖率超过90%。此外,软硬件协同框架驱动的页面回收机制降低了关键路径访问远端内存的次数,与内核默认的回收机制相比,最多可以降低30%。

本文组织如下。第1 节介绍研究背景与相关工作;第2 节介绍软硬件协同框架的设计细节;第3 节介绍预取与替换框架实现;第4 节介绍测试平台及系统实现;第5 节介绍实验评测方法及结果;第6 节对全文进行了总结。

1 背景

本节首先介绍了现代服务器架构与软硬件协同框架的背景。然后讨论了可以从使用软硬件协同框架中受益的几个用例。最后介绍了几种其他类型的远端内存系统。

1.1 现代服务器架构

图1 显示了典型的服务器架构,最后一级缓存(last level cache,LLC)、内存控制器(MC)和高速串行计算机扩展总线标准(peripheral component ihterconnect express,PCIe)控制器通过处理器内部总线互连。MC 通过标准双倍速率(double data rate,DDR)总线与动态随机存取存储器(dynamic random access memory,DRAM)芯片通信。PCIe 控制器通过PCIe 总线与I/O 设备通信。当LLC 发生缺失时,它将通过处理器总线向MC 发送请求。随后,MC 发出DDR 请求。显然,MC 知道所有CPU 的全部内存访问。由于直接向DRAM写入访存信息消耗额外的内存带宽,并且在操作系统读取访存信息时需要将数据从DRAM 读到LLC。所以,本文设计了软硬件协同框架,在MC 中增加硬件逻辑,将缓存块粒度的访存请求转化为页粒度后,再通过内存传递给操作系统,降低传输时的带宽消耗。

图1 典型的服务器架构图

1.2 基于内核的远端内存系统

这类远端内存系统依靠虚拟内存系统来透明地访问远程内存。因此,应用程序无需修改自身代码,直接使用远程内存。但这种透明不是没有代价的。缺页会引发高的软件延迟,甚至高过网络延迟,这使得软件的开销成为访问远程内存的瓶颈。

作为案例研究,本文评估了Fastswap[3],这是谷歌在2020 年基于Linux 内核的Frontswap 接口[12]提出的远端内存系统。研究发现Fastswap 使用单核从远程读取页面大约需要6 μs。图2 显示了当增加线程数量时的延迟趋势,并详细介绍了Fastswap 中的各种组件(暂时禁用预取)。本次测试将本地内存限制为1 GB,而程序使用的总内存为8 GB。线程固定在不同的内核上,每个内核从4 kB 页面读取8 字节整数并将所有值相加(即每页512 次加法)。很明显,Fastswap 无法随着线程数量的增加而扩展。这是由于现有VMS 中固有的粗粒度锁定和同步函数调用。

图2 当线程数量变化时,关键路径上延迟的变化

克服上述VMS 开销的一种方法是通过预取远端内存页面到本地内存,从而尽可能避免VMS 数据路径中的I/O 传输时间。Fastswap 使用默认的内核预取策略来读取出错页面[3]之后的后续7 个页面。假设,如果处理器运行一个顺序扫描内存区域的程序,上述简单策略应该具有完美的准确率和覆盖率(定义见第4 节)。然而,如图3 所示,随着并行度的增加,这2 个指标都会下降。使用10 个线程,准确率下降到85%,而覆盖率仅为81%。优化的预取解决方案Leap[5]尝试使用基于监测窗口选择最适预取偏移的在线预取算法来改进远端内存系统。然而,它的算法不能充分利用预取的好处。根本原因在于,Fastswap 和Leap 都只从缺页或扫描页表中的访问位中获知访问信息,这些信息是不频繁、不准确、陈旧的且获取成本高昂。

图3 当线程数量变化时,准确率与覆盖率的变化

为了展示软硬件协同框架的优势,本文将其与Fastswap 集成。从软硬件协同框架的角度来看,Fastswap 是一个应用程序。特别是,本文将Fastswap的默认顺序预取策略替换为基于流的策略,该策略使用软硬件协同框架提供的丰富应用程序访问信息进行训练。为了克服Fastswap 中的可扩展性瓶颈,本文在单独的异步数据路径中运行软件协同框架和新算法,独立于传统VMS 路径。本文选择优化Fastswap 是因为它在大多数情况下比Leap 具有更好的性能。

1.3 页面交换和驱逐

页面交换在现代数据中心中起着关键作用。例如,谷歌和Meta 都部署了依赖内核页面交换来识别冷内存的远端内存系统[1-2]。在Linux 中,页面交换使用近似最近最少使用(least recently used,LRU)列表来选择要驱逐的页面。通常,内核在2 种情况下更新这些列表:(1)内核在被某个内核函数(例如写时复制)使用时主动更新页面访问标志位;(2)内核调用守护线程(即kswapd)定期扫描页表中的访问位,然后相应地调整它们在列表中的顺序。然而,这2 种方法都会产生不频繁、不准确、陈旧的页面访问信息。因此,使用此类信息排序的LRU 列表无法捕获实际的内存访问模式。

本文通过使用软硬件结合框架的丰富内存访问信息替换基于访问位的方法来改进默认LRU 列表。此外,当有替换请求时,替换框架会优先考虑具有流式访问模式的页面,因为与随机访问的页面相比,它们不太可能被再次使用。

1.4 其他类型的远端内存系统介绍

应用集成的远端内存系统。这类系统需要通过修改应用来达到访问使用远端内存的目的,一些研究通过构建定制的应用接口或数据结构[13-14],让用户更方便且更加灵活地使用远端内存。然而,与基于内核的远端内存系统相比,这种方式丧失了透明性与通用性。用户不但需要重构代码,而且引入了复杂的远端数据管理问题。

虚拟化的运行时远端内存系统。这类系统改变了其中的内存管理组件,例如Java 虚拟机(Java virtual machine,JVM)的垃圾收集[15],使它们对远程内存更加友好。尽管如此,它们被限定在特定语言(如JVM 的用户),因此通用性有限。

基于总线扩展的远端内存系统。这种系统通过一致性协议扩展来实现远程内存的访问[16-18]。尽管这种方式有望完全实现透明性、通用性和高性能的远端内存系统,并引起极大的关注[16-17]。但是,它有2 个限制:(1)它无法利用本地内存作为缓存来减轻应用使用远端内存造成的性能损失;(2)由于同步load/store 指令可能经过多个节点进行转发,其延迟高达几微秒,因此每个未完成的内存访问都需要至少持有一个硬件资源,直到操作完成[18]。因此,数据中心运营商更倾向于在一个机柜搭建基于总线扩展的远端内存系统[7]。

2 软硬件协同框架系统设计

图4 描述了软硬件协同框架的系统架构。本文在MC 中部署了一个热点页面提取表。该单元截获所有LLC 未命中的内存请求,将缓存块粒度信息转化为页粒度信息,然后其将热点页面信息发送到保留的缓冲区。MC 向缓冲区尾部写入访存信息,同时更新写指针。而专用的软件线程不断从缓冲区头部读取访存信息,然后通过反向页表将物理页面转化为虚拟页面与进程号,给替换模块与预取模块使用。

2.1 热点页面表

内存控制器可以收到所有缓存缺失信息。简单地将所有这些信息提供给操作系统会消耗过多的内存带宽。另外,如果软件负责过滤信息,则增加了软件复杂度和计算资源。本文希望提供尽可能多的内存访问信息以接近应用实时页面访问行为。为了在不消耗过多内存带宽的情况下实时输出内存信息,本文添加了一个轻量级的热页检测模块,在MC 中将基于缓存块粒度的访问转换为热点页面级别的访问信息。

热点页面表过滤了写类型的请求,仅处理读类型请求,原因有2 个:(1)任何读操作都会立即生成读请求,而写操作会首先生成读请求并将数据写入处理器缓存,写内存的请求会在缓存发生替换的时候产生;(2)远程直接数据存取(remote direct memory access,RDMA)网卡(network interface card,NIC)使用DMA 写入将页面从远程获取到本地内存中时,导致大量写入访问。没有简单的方法将它们与应用程序生成的正常访问区分开来。

为了要识别热点页,一种直接的方法是跟踪所有物理页的访问次数,然后在一个时间窗口(例如,100 μs)内找到被访问过N次的物理页。然而,这种方法需要大量的硬件资源,这些资源无法放入MC中。因此,本文构建了一个热点页面提取表来仅跟踪M个页面的访问计数。在图5 中,热点页面表被组织为具有LRU 替换(M=64)的16 路4 组关联缓存。表中的每个条目都记录了物理页面号(physical page number,PPN)、读取访问次数、一个发送位表示该条目被识别为热页并被提取,以及一个用于替换的LRU 位。PPN 的最低2 位用作集合索引。

图5 热点页面表结构图

现在可以详细描述整个流程。当热点页面表接收到内存访问请求时,将其缓存块对齐的地址转换为物理地址,并使用物理页面号来查询表条目。如果没有找到,则将其插入表中。如果找到,检查发送位是否被置1,如果是,不进行处理。否则,增加这一项的访问次数。一旦访问超过阈值N,就提取物理页号并将其标记为热页。热点页面表中的项数越多,可以同时跟踪的物理页就越多。本文使用4 组的热点页面表,即最多可以同时跟踪64 个不同的物理页面。

N的影响。一个4 kB 的页面包含64 个缓存块,因此N的范围是1～64。如果N太小,例如N=2,则会提取到更多的热页面,并且提取的内存请求更接近应用程序的实时页面访问。但是,它包括对同一页面的更多重复提取,从而导致消耗更多的内存带宽。表1 显示,当N小于8 时,提取的热点页数显著增加,传输过程中更多的内存带宽被消耗,例如PageRank,因此应用程序性能下降(3% forN=4)。如果N太大,例如,N=32,一个热点页面可能在被访问N次之前就被替换,对提取的内存信息造成缺失,影响预取覆盖率和应用性能。为了在内存带宽消耗和页面提取的及时性之间取得最佳平衡,本文选择N=8 作为默认值。

表1 N 变化时,提取的热点页面数量占访存请求个数占比(%)

多个内存通道的影响。当多个通道设置为interleave 模式时,同一物理页面的不同缓存块被分配到不同的通道中。在这种情况下,热点页面表需要减少N。虽然这可能会导致重复的热页面提取,但可以在软件中对它们进行去重。当多个通道没有设置为interleave 时,从不同的MC 中提取不同的热页,可以在软件中将它们合并。

2.2 反向页表

系统软件持续监控内存中缓冲区的热点页面信息,然后由反向页表对这些访存记录进行处理。这些访存记录仍然是物理地址。然而,虚拟内存系统需要虚拟地址以便于更好地发现访存规律[19]。Linux 内核中的有默认的反向映射表就是为此目的而设计的,但默认的反向映射表至少需要4 次内存访问才能完成一次转换,这样的开销过大,因此需要设计一个简易且快速的反向页表。

本文构建了反向页面表,这是一种为软硬件协同框架的需求量身定制的轻量级翻译机制。反向页表被组织为一个由物理页号为索引的数组。这个数组存储在操作系统预留的内存区域,为了避免一致性问题,需要将这块内存区域的属性设置为不经过缓存。图6 显示了每一项反向页表的具体结构,它包含16 位的进程号与40 位的虚拟页面号。每次查询物理页面对应的虚拟页面号与进程号时,反向页表首地址与物理页面号相加的地址就是当前物理页面号反向页表项的地址。

图6 反向页表项结构

3 使用样例

基于软硬件协同框架的完整访存信息,本文构建了2 种使用样例展示软硬件协同框架如何提升虚拟内存系统的性能,即一个新的基于完整访存信息的LRU 的页面替换系统和一个基于RDMA 的远端内存的预取系统。

3.1 页面替换

Linux 内核中现成的LRU 页面列表是根据页表访问位以及其是否属于活跃链表进行排列的。本文构造一个由软硬件协同框架驱动的页面替换系统来改进它。首先,为了绕过内核复杂的数据路径,本文构建了一个单独的数据驱逐路径。一旦替换系统检测到整个服务器存在内存不足的情况,它将选择一组要收回的页,并指示内核完成收回过程。其次,替换系统基于LRU 规则维护了一组页面列表,该列表根据完整的来自软硬件协同框架的访问信息构建。最后,替换系统针对不同的访问模式,使用不同的替换策略。当选择驱逐的页面时,本文优先对流访问之后的页面进行驱逐,这是因为流访问模式的页面与遵循随机访问模式的页面相比,有更小的再次被访问的可能性。本文使用页面流表来标识哪些页面属于流(详见3.2 节)。

3.2 页面预取

基于软硬件协同框架提供的完整访存信息,本文构建了一个基于流的预取器,称为软硬件协同框架驱动的预取器。这个预取器能够指导Fastswap 从远程异步地预取(无需等待缺页发生)。同时,本文还将上述软硬件协同框架驱动的替换系统集成到Fastswap 中。

预取器中的一个核心思想是预取页面流,即一个固定步幅的访问序列。一个应用程序可以同时具有多个页面流。预取器维护一个流训练表,每个条目代表一个页面流。如图7 所示,流训练表有64 个条目,这在大多数情况下就足够了。使用LRU 策略管理条目。此外,一个流训练条目最多可以记录5个虚拟页号。

图7 流训练表结构图

预取器工作流程如下:当新的{虚页号,进程号}到达时,首先找到与新进程号相等的所有流训练表中的条目;然后将新虚页号与条目中虚页号数组的第一项进行比较,如果两者差值小于一定阈值(设置为64),那么预取器则认定新页面属于这个页面流;最后,预取器会将新页面的虚页号依次存储在其流训练表对应条目中的虚页号数组中。当虚页号数组已满时,将计算这个流的步长(即虚页号数组中相邻虚页号之间的距离),并找到出现次数最多的步长。这样,预取器确定用于预取的虚页号是页面流的结束页+i×步长,其中i是预取偏移量。为了防止系统和网络延迟对预取的影响,本文设置i=100 以确保页面在应用程序访问之前及时到达。在图7 中,新页面{2,8}到达,确定其属于流训练表中的第一个条目,计算步长等于2,那么预取的页面是8 +2 ×100=208。

4 具体实现

本研究在x86 服务器上构建了软硬件协同框架和2 个使用样例的原型系统。本研究在用户空间中实现了大部分软件功能,只在内核空间中留下一小部分用于与VMS 交互。这种方法很灵活,因为它可以实现快速的开发迭代、易于编程和在线系统升级[20-21]。本研究构造了一些系统调用和共享内存,使软硬件协同框架可用于用户空间代码。对于这2个使用样例,本研究在用户空间中构建了基于流的预取器和LRU 页面列表。它们通过新的系统调用与内核进行通信。

4.1 硬件测试平台

大多数MC 都是供应商锁定的,并与CPU 和LLC 打包在一起成单个模具,因此不能修改MC 来实现热点页面提取表。本研究在x86 服务器上构建了一个仿真验证原型,如图8 所示。它有几个主要组件。为了模拟记录单元中的跟踪部分,本研究将一个名为HMTT[10-11]的基于硬件的内存跟踪工具附加到MC 和DRAM 芯片之间的链接上。HMTT 工具可以通过在DDRx内存总线上侦听通过MC的DDR数据包来实时捕获内存访问信息。本研究将HMTT插入DIMM 插槽,并将DRAM 安装到HMTT 板上。HMTT 可以配置为监视一定范围的物理内存空间。

图8 测试平台结构图

HMTT 将在一个节点收集的内存跟踪通过PCIe转发到另一个接收节点,而后者又将访存信息保存在其本地固态硬盘(solid state disk,SSD)上。为了在同一节点捕捉和使用访存信息,本研究修改了HMTT 配置。如图8 所示,HMTT 位于Socket 0 的DIMM 和内存0 之间。它可以获得对内存0 的实时内存访问。通过将操作系统配置为仅在内存0 上运行,HMTT 可以监控所有正在运行的应用程序的内存访问。内存控制器中的热点页面提取表仅输出热页,因此它消耗的内存带宽很少,并且可以写入与应用程序相同的DRAM,而HMTT 则输出所有内存访问信息。为了避免在同一个内存上的内存带宽干扰,本研究配置HMTT 以将收集在内存0 中的访存信息写入内存1,通过PCIe 将访存信息发送到硬件的接收卡,该接收卡负责将它们写入内存1 中的保留区域。

本研究的原型系统在功能上等同于本研究的设计,并且足以用于验证目的。然而,该原型存在以下限制:(1)HMTT 受限于其现场可编程门阵列(field progrmmable gate array,FPGA)频率,因此在捕获吞吐量上存在上限;(2)它需要大量的工程工作(例如,将HMTT 与单独的PCIe 设备连接)并产生更高的构建成本;(3)它增加了延迟,因此影响了访存的及时性。如果本研究的设计集成到芯片或MC 中,例如使用开源硬件平台[22],这些问题就不存在了。本研究的硬件实际部署是非侵入式的,应该可以在各种CPU 平台上运行。这一探索留给未来的工作。

4.2 运行软件

本研究的设计原则是在用户空间中实现大部分功能并最小化内核更改。这使其能够快速迭代并无缝升级软硬件协同框架。

内核模块。只有一部分反向页表是在内核空间中实现的。具体来说,在操作系统启动时,为反向页表保留了一个连续的物理内存区域。该表是图6 描述的反向页表条目的平面数组,按物理地址索引。当软硬件协同框架首次启动时,其将扫描所有现有页表以构建初始反向页表。同时为VMS 中的一些函数(例如pte clear、setpet)插入轻量级回调函数,以保持反向页表更新。为了进行高效通信,本研究还实现了一些用于低吞吐量控制任务的系统调用和用于高吞吐量数据共享的共享内存。

用户态模块。本研究在用户空间中实现了过滤模块和反向页表。本研究用一个线程模拟热点页面表,同时用一个固定线程来轮询循环缓冲区的读写指针。只要缓冲区不为空,线程就会从读取热点页面信息。在当前的实现中,线程将直接将访存信息发送到热点页面表中。

替换模块。替换模块使用C 语言来实现,它通过共享内存接受来自软硬件协同框架的输入。本研究还为其实现了一个新的系统调用,系统调用接受来自用户空间的替换请求,然后将页面替换到远端内存。然后,它会返回替换成功的页面号。为了提高可扩展性,本研究不等待I/O 传输完成,而是在发出换出请求后立即返回。一旦I/O 传输完成,内核就会相应地更新页面状态。

预取模块。与替换模块类似,预取模块也是用C 语言实现的,并通过共享内存与软硬件协同框架通信。由于远端内存系统具有波动的工作负载,预取器可以通过调整预取线程的数量来自动扩展其计算能力,每个线程都接受来自软硬件协同框架的输入并通过新的系统调用独立地与Fastswap 通信。

本研究改进了内核的预取接口,因为它受限于同步的数据路径和粗粒度锁。因此,本研究将交换接口分为2 个步骤。第1 步是寻找空余内存并将预取请求发送到基于的RDMA 交换系统,例如Fastswap 中的Frontswap。第2 步立即将控制权返回给调用线程,无需等待请求完成。一旦请求完成,RDMA NIC 发送一个中断,中断处理程序(构建在工作队列子系统之上)将完成页表相关操作。此外,本研究用细粒度的页面锁替换了粗粒度的锁,这大大提高了并行度。本研究对内核的所有更改都不会干扰Fastswap。在Fastswap 之上运行的应用程序无需任何更改即可轻松享受软硬件协同框架带来的优势。本文将与Leap[5]或Infiniswap[4]等其他分类存储系统的集成留给未来的工作。

5 测试

在本节中,首先评估2 个构建在软硬件协同框架的使用奖励:使用实际应用程序进行页面替换和预取。然后,对软硬件协同框架本身进行了测试。

测试台和工作负载。如图8 所示,测试台有2个通过RDMA 连接的服务器,一个是运行软硬件协同框架的本地服务器,另一个用作远程内存。这2台服务器都有一个14 核Xeon E5-2680 CPU、35 MB,20 路LLC、64 GB DRAM 和一个56 Gbps Mellanox ConnectX-4 NIC。表2 显示了本文实验中使用的14个大规模内存应用程序。

表2 测试应用

5.1 页面替换

对于这2 个用例,本文首先评估替换框架。本文使用Linux 默认替换机制及其kswapd 作为对比项。本文使用由软硬件协同框架的完整访存信息支持的LRU 列表、流访问模式优先替换以及2 种优化同时使用来评估替换框架。使用Fastswap[3]作为基础交换系统,因此页面被替换到远程内存。使用应用程序完成时间加速比和访问远端内存次数减少百分比2 个指标进行比较。访问远端内存次数减少百分比定义为与Linux 默认替换机制相比减少的百分比,其值越高越好。

图9 和图10 报告了使用软硬件协同的替换框架的8 个实际应用程序的加速比和读远端次数减少比例。其中,美国国家航天局并行基准测试(NAS parallel benchmarks,NPB)-多重网格(multigrid,MG)、NPB-快速傅立叶变换(fast Fourier transform,FT)和Spark Graphx 的访问中大多为随机访问,因此,具有LRU 优化的替换方法比流替换方法更好。相比之下,NPB-整数排序(integer sort,IS)的访问模式以流模式为主,因此流替换方法让其性能提升最高(1.3 倍)。其原因是通过优先对流页面的访问,尽可能地保留了随机页面到本地内存,降低了对远端内存的读取次数(图10)。由于K-means 的访问与Stream 类似,因此替换框架对其都不起作用。

图9 不同替换策略下的加速比

5.2 页面预取

本文将软硬件协同的预取框架与Fastswap 集成,并使用各种实际应用程序进行测试,将其与Fastswap 与Leap 进行比较。然而,由于数据路径实现速度慢,Leap 的性能比其他2 个差得多。因此,为了更好地说明,本文省略了Leap 的结果。本文使用2 个指标来衡量预取性能:准确率是预取的页面命中次数与发出的预取页面数的比;覆盖率是预取的页面命中次数与没有预取时访问远端内存数量的比。本文还使用应用程序完成时间与其在Fastswap的完成时间的比来统计新框架对应用的加速比。对于所有测试,本文将本地内存设置为应用程序占用空间的50%。

图11 显示了使用软硬件协同预取框架对应用程序完成时间的加速比。对于QuickSort 和K-means-OMP,与没有远端内存的本地场景相比,即使应用一半的内存在远端,软硬件协同框架也不会导致应用性能下降。这是因为软硬件协同预取框架可以准确预测应用访问模式并将页面异步预取到本地内存中,完全消除缺页。使用软硬件协同预取框架对所有应用的平均加速比为32.2%,其相比于Fastswap最多加速48.2%,最少为11.4%。

图11 应用在软硬件集合预取框架下的加速比

同时,本文进一步比较了它们的准确性和覆盖率。如图12 所示,软硬件协同预取框架的平均精度超过97%,这意味着只发出少数错误预取,并且本地内存没有受到污染。然而,Fastswap 的平均准确率仅为71.1%。图13 显示了软硬件协同预取框架的预取覆盖范围分为2 部分:流命中和swap 命中。swap 命中是底层远程系统在出现缺页时发出的预取页面数。本质上,软硬件协同预取框架是对运行在同一服务器上的远程内存系统的补充。流命中是流形成后发出的预取页数,不会导致缺页产生。实验表明QuickSort 预取覆盖率最高,K-means 应用程序完成时间与其内存都在本地内存时非常接近。

图12 软硬件集合的预取器的准确率

图13 软硬件集合的预取器的覆盖率

5.3 替换与预取结合测试

图14 展示了当替换框架与预取框架结合在一起时对应用的影响。对于除K-means 之外的所有应用程序,预取与替换框架结合时的性能都优于其他设置。通过共同使用同一张流训练表,预取框架减少了流页面的缺页次数,而替换框架减少了随机页面的缺页次数。由于K-means 的随机页面较少,预取与替换框架结合时相比单独的预取框架几乎没有提升。

5.4 硬件设计可行性

本文在Verilog 中实现了热点页面表,以验证所提出硬件设计的可行性以及它们的内存带宽消耗。本文利用CACTI[23]使用22 nm 技术节点估计面积和静态能量消耗。热点页面提取表需要的面积为0.000 252 mm2,它的静态功耗是0.0959 mW。

6 结论

本文介绍了一种软硬件协同框架,通过在内存控制器中增加热点页面表,将热点页面信息不断写入内存中的缓冲区,软件通过对缓冲区的不断监控,获取应用实时访存的物理地址,从而弥合操作系统和应用程序内存访问行为之间的语义鸿沟。同时,本文建立了一种高效的翻译机制,将物理地址高效地翻译为虚拟地址与进程号。通过对访存信息的学习,本文构建了高精度的异步预取框架与替换框架,降低了应用关键数据路径的开销,提升了远端内存系统的性能。值得一提的是,本文利用内存跟踪工具构建了一个原型仿真系统,证明了预取与替换框架所带来的好处。本工作可能为改进各种基于虚拟内存的系统打开大门。