LightPC: Hardware and Software Co-Design for Energy-Efficient Full System Persistence(论文阅读翻译)

（注：课程作业要求，机翻自己看的）

Abstract:
我们提出了LightPC，一种轻量级的持久性中心平台，以使系统对电源故障具有鲁棒性。LightPC由硬件和软件子系统组成，分别被称为开放通道PMEM（OC-PMEM）和持久性中心操作系统（PecOS）。OC-PMEM通过解除新型存储介质与传统PMEM复杂之间的物理和逻辑边界，消除了易失性和非易失性数据结构之间的界限。PecOS提供了一个单一的执行持久性切断，以便在电源故障的情况下快速将执行状态转换为持久信息，这可以消除持久控制开销。我们使用自定义系统板制作了LightPC的计算复杂和OC-PMEM的原型。PecOS基于Linux4.19和Berkeley引导程序在硬件原型上实现。我们的评估结果表明，OC-PMEM可以使用户级性能与仅使用DRAM的非持久性系统相当，同时消耗的电源功率降低了73％，能耗降低了69％。与传统持久性系统相比，LightPC还缩短了各种HPC、SPEC和内存数据库工作负载的执行时间，平均缩短了4.3倍。

1、INTRODUCTION:
在数据中心和高性能计算等服务器级计算领域中，长时间运行的应用程序经常面临意外的电源故障。广泛的服务器服务采用日志记录和检查点重启等机制，以使系统在电源故障时具有鲁棒性和崩溃一致性[3-6]。虽然这样的持久性机制可以通过恢复其已提交的事务来控制崩溃，但实际上它们由于数据复制、由单个线程串行化的I/O操作以及用于数据管理的锁/屏障等多个方面而遭受显著的性能下降[7-10]。此外，日志记录和检查点会浪费系统资源和电力来处理持久性控制请求。

相反，我们可以利用一种支持10倍更高存储容量和出色的非易失性能力的持久性内存模块（PMEM），由3D-Xpoint提供，它是相变存储器（PRAM）的一种变体[15-17]。然而，采用PMEM的现代系统不幸地经历了意外的性能和延迟变化[18-20]。例如，报告称使用PMEM的处理器延迟是不确定的，并且变化显著，这比使用DRAM的传统系统要差3倍。意外延迟变化背后的原因之一是PMEM的内存复杂性和DIMM级微体系结构是自包含的，类似于高性能固态硬盘，而不像DRAM DIMM。

此外，如果目标系统将持久性视为一等公民，则PMEM也无法避免崩溃一致性管理，这会降低整体性能。 PMEM使用内部DRAM缓冲区，并利用本地节点的外部DRAM作为内存缓存，以追赶DRAM性能。由于混合设计，PMEM满足服务器和应用市场的各种需求。然而，它需要支持容错软件库，定期刷新缓冲区并在DRAM和PMEM之间同步执行状态。这不幸地产生了超过100％的空间开销，并显著降低了性能。在系统坚持使多个运行在其核心上的进程中的内存数据持久且一致的情况下，我们观察到PMEM的用户级性能变差了8.7倍，功耗增加了1.6倍，与仅使用DRAM的传统系统相比。我们将在第II-B节中讨论这一观察的细节。

我们提出了一个轻量级持久化中心平台(LightPC)，以使系统对电源故障具有弹性。这项工作的洞察力很简单且全新，但尚未体现在实际系统中。如果重新考虑当前存储子系统的垂直设计，可以通过使所有数据结构和执行流程持久化来解决电源故障控制开销，并消除PMEM混合设计所强加的频繁内存刷新/同步。LightPC通过消除持久和非持久数据结构之间的物理和逻辑边界，支持轻量级正交持久性。为此，我们需要首先使PRAM延迟具有确定性，并最小化DRAM相关硬件模块所引起的性能影响。此外，我们需要确保一个稳定的CPU控制机制，以适当地挂起/恢复存储在CPU端的许多非持久状态，并使它们持久化，以使在不同核心上运行的多个进程/线程可以继续它们的工作而不会对电源故障产生负面影响。

本文提出了一种硬件和软件协同技术，包括两个主要组件：i）开放通道PMEM（OC-PMEM）和ii）持久性中心操作系统（PecOS）。OC-PMEM免除了非持久性内存路径，降低了PRAM访问的惩罚，而PecOS则快速将正在运行的进程的执行状态转换为持久性状态。具体而言，OC-PMEM解除了新型内存介质与传统PMEM复杂结构的束缚。同时，它让可靠性和并行管理与内存子系统相耦合。OC-PMEM最小化了数据通路中的非持久性状态，从而表现出确定性能力。另一方面，PecOS修改了Linux任务调度程序和电源管理背板，提供了一个单一的执行持久性切割，多个核心可以确保在停电时它们的状态是持久的。它保证在比标准停电保持时间短得多的时间内，可以将即时内存操作和非持久性执行状态（例如，进程控制，外围上下文等）安全地存储在持久空间中。稍后，PecOS会立即从持久性切割中恢复和执行所有已下线的进程。LightPC不坚持在源级别进行修改，因此对新型非易失性内存具有透明性并与其良好协调。

以下总结了我们的贡献：

Open-Channel 架构用于 PMEM。 我们引入了 Open-Channel 架构，以实现 PMEM 的确定性性能，该架构由两个主要硬件模块组成，持久支持模块和裸机 PRAM DIMM 通道。前者管理资源冲突和可靠性问题，位于计算复杂度下方，从内存访问路径中删除 DIMM 端固件和内部易失性存储器组件。后者旨在将 PRAM 媒体暴露给主机，但增加并行性以尽快服务即时请求。

透明的全持久性机制。 在实际系统中，使多核执行阶段的执行状态在任何地方持久化并不容易。PecOS通过实现一个多步骤的下线和上线机制（称为Stop-and-Go，简称SnG）来提供持久化切割。SnG首先确保所有系统上下文都被安全地存储。然后，SnG停止所有进程并锁定它们在多个核心上。一旦它确保了所有核心的环境不变，SnG暂停外围设备并冻结它们的上下文，并将每个核心的易失性状态转储到持久空间中。

实用的非易失性计算和原型。 检查完整系统的持久性需要精细的电源控制和在不同硬件和软件障碍之间进行实际的系统空间探索，这些都无法通过模拟和仿真研究来很好地捕捉到。我们使用自定义系统板原型化了LightPC的计算复杂度和OC-PMEM，而PecOS是在Linux4.19上实现的。该原型还包括连接到处理器的多点网络的多个裸机PRAM通道。

我们在实际系统上进行的评估结果表明，运行在LightPC上的HPC、SPEC和内存数据库工作负载的功耗比非持久性系统低73％，性能相当。与持久性系统相比，LightPC还缩短了这些工作负载的延迟，平均缩短了4.3倍，同时节省了3.6倍的能量。

2、Background
A、硬件基础
Optane PMEM是支持现代计算机数据持久性的基础。PMEM不仅是一种简单的DIMM技术，而且是一种综合系统解决方案，涵盖了多种用户需求。因此，PMEM提供块存储（扇区模式）、非持久性工作内存（内存模式）和非易失性内存（app-direct模式），这些应该在系统初始化时进行配置。

PMEM硬件复杂性。 图1展示了PMEM的计算复杂性。PMEM将几个本地节点DRAM DIMM和PMEM DIMM放在一起组成内存系统。为了适当地管理两种不同的存储技术，它采用了三种类型的存储控制器，即PMEM控制器、DRAM控制器和近存储器缓存(NMEM)控制器。DRAM控制器管理本地节点DRAM DIMM，而PMEM控制器独立地与PMEM DIMM进行接口。NMEM控制器处理这两个存储控制器，将PMEM数据缓存到DRAM中。为了最小化缓存开销，NMEM控制器利用共享内存接口snarf，重叠由本地节点DRAM和PMEM之间的数据传输引起的延迟。存储模式的PMEM使用了这三个控制器，具有类似DRAM的性能，但放弃了PRAM带来的所有非易失性优势。另一方面，app-direct模式和sector mode模式的PMEM禁用DRAM和NMEM控制器，从而将PMEM DIMM作为持久存储器暴露给CPU。具体而言，在这两种模式下，PMEM DIMM被排除在工作内存空间之外，并映射到挂载在/dev下的设备文件中。因此，计算复杂性可以支持带有不同类型持久性控制支持的数据持久池，但系统中运行的所有应用程序和内核线程仍驻留在本地节点DRAM DIMM上，而不是PMEM DIMM上。

PMEM DIMM结构。 工业文件表明，PMEM DIMM包括比DRAM DIMM更复杂的内部结构，但没有详细信息。图2a通过对256GB PMEM DIMM产品进行逆向工程展示了PMEM数据通路和内部架构。PMEM DIMM采用负载-存储队列（LSQ），重新排序传入的请求，并执行写组合（write combining）操作，如果可能形成256B请求（这是DIMM级PRAM介质的物理访问粒度）。为了处理64B的高速缓存行请求，PMEM DIMM将一组SRAM和DRAM模块与PRAM设备集成到设备中（作为两级包容缓存）。SRAM主要执行256B大小的读取和修改操作，而DRAM用于地址转换和缓冲请求为4KB，以利用并行性。目前没有官方文件来证明为什么4KB操作很重要，但我们推测这样的4KB缓冲有助于减少元数据大小，例如映射表和磨损级别计数，以及提供与区块存储（sector mode）操作的兼容性。所有这些内部组件都由PMEM固件管理，类似于现代SSD。即使目前的PMEM配置可以满足各种需求，但复杂的内部结构和多个控制器/固件的组合不幸地引入了变化和不确定的延迟。

延迟变化。 由于没有公开可自由修改的PMEM，我们建立了一个硬件原型，可以使用真实的2x nm交叉点裸片PRAM比较DIMM级和银行级的PMEM性能。我们在PRAM顶部集成了一个仿真模块，用于DIMM级性能分析。图2b显示了随机访问的读写延迟变化。为了更好地比较，我们还包括DRAM读/写延迟在分析中。由于内部DRAM / SRAM缓冲区，DIMM级写入比裸片PRAM上的写入时间短2.3×∼6.1×。然而，DIMM级读取需要比裸片PRAM长2.9×的时间。请注意，内部缓冲架构可以隐藏PRAM的长写延迟，从而使PMEM写入在某种程度上甚至比DRAM写入更好。但是，即使裸片PRAM的读延迟非常类似于DRAM（仅差异为1.1％），由于多缓冲和PMEM固件，不能直接从底层PRAM提供读取。由于最新数据可能存在于SRAM或DRAM中的任何一个中，因此需要支付查找成本和每个级别的包含缓存存储器访问成本。这会导致读写延迟不确定，并使DIMM级性能具有变化性。

B、持续经营
PMEM使用应用程序直接模式仍然需要运行时支持，以将其设备文件映射到虚拟地址，并从处理器视角使PMEM DIMM持久化。

数据持久性控制。 图3a展示了如何从应用程序角度将PMEM用作持久性池。由于Linux系统将PMEM公开为设备文件（/ dev / XX），因此需要直接访问（DAX），它通过Linux内存管理（MM）的内存映射文件（mmap）直接将数据映射到应用程序地址空间。 DAX的地址转换开销可以忽略不计，因为DAX只需将相应的虚拟地址（VA）添加到目标文件中的偏移量即可计算物理地址（PA）。为了实现数据持久性，我们需要在PMEM上使用PMDK的持久对象管理库（libpmemobj）。PMDK数据持久性的主要思想是将应用程序的数据管理为对象，并使用持久性指针（即对象ID），而不是进程的VA。例如，图3b展示了如何使用libpmemobj持久地存储链接列表。链接列表的每个条目都可以是一个对象，并且链接列表的根对象的VA与Linux的MM的内存映射的VA相同。如果创建了一个附加的列表条目，libpmemobj会从根对象地址计算新对象的偏移量，并将其用作对象ID。由于libpmemobj使用基于偏移量的指针，因此应用程序应计算每个内存访问的VA，这会引入频繁的软件干预和开销。还有一种类似的方法，将与其进程相关联的VA存储到每个对象中。请注意，libpmemobj不会默认强制刷新和同步，因此需要明确声明事务行以使对象持久化。

性能开销。 在这项分析中，我们准备了四种PMEM解决方案的组合，并将它们与仅在本地节点DRAM上执行所有应用程序的DRAM进行比较。mem-mode和app-mode将PMEM设置为DRAM缓存内存模式和带有DAX的应用程序直接模式，object-mode使用PMDK的libpmemobj在app-mode之上管理测试过程中的多个地址对象，而trans-mode通过显式管理对象来使所有更改持久化。具体而言，trans-mode将访问全局和堆内存的操作代码块（插入/删除）包装在PMDK的事务API（TX_BEGIN / TX_END）周围。我们使用Intel的白金级节点，其中包含1.5TB的Optane PMEM和190GB的本地节点DRAM，并评估17HPC、SPEC和内存数据库工作负载[37-41]。图4a和4b分别分析了平均延迟和功耗。结果仅针对内存子系统功耗（不包括所有其他计算资源），由LIKWID测量。

通过DRAM缓存和snarf的优化，DRAM-only和mem-mode之间几乎没有区别，仅有1.3%的差距。虽然DAX在应用程序级别的地址转换方面开销很小，但是相比mem-mode，app-mode的执行时间平均增加了28%，功耗增加了47%。这是因为它需要额外的内部DRAM/缓冲区查找和设备级别的地址转换来进行加载/存储。当我们坚持对多个进程进行数据持久化时，object-mode的延迟和功耗分别增加了1.8倍和1.6倍。object-mode需要一组初始设置来初始化对象根和头，以及运行时对多个对象的地址转换进行干预。如果要使数据持久化，与DRAM-only相比，trans-mode进一步增加了应用程序的延迟，平均增加了8.7倍。对于事务，libpmemobj使用pmem_persist()刷新缓存并同步内存。由于禁止用户访问缓存数据及其PA，它强制CPU缓存控制器迭代地访问pmem_persist()给定的VA范围内的缓存块。

3、轻量级以持久性为中心的平台

A、硬件子系统概述
为了消除内部缓冲区、PMEM固件和基于设备文件的操作带来的开销，我们将所有裸机PRAM设备暴露给计算复杂体系结构，同时在控制器侧保留最小的硬件逻辑，例如并行性和尾延迟管理。这种新的系统设计被称为开放通道持久内存(OC-PMEM)，可以消除所有与DRAM相关的硬件，使得它将易失性资源保持小，以便操作系统可以快速将它们的状态变为持久。为此，如图5a所示，OC-PMEM实现了两个主要组件：i)持久支持模块(PSM)和i)裸机PRAM DIMM通道，称为Bare-NVDIMM。PSM管理资源冲突和可靠性问题，而Bare-NVDIMM旨在增加并行性，尽快执行缓存刷新。所有运行中的进程都可以通过PSM向OC-PMEM发出内存请求，就像传统内存一样。换句话说，应用程序和操作系统内核直接在PMEM上运行，这使得它们的堆栈、堆和代码区域在执行期间几乎是持久的。

基本理念。 构建可替换DRAM的非易失性存储器（NVM）子系统的最大挑战是要赶上DRAM的读取性能，而不是写入性能。有许多研究利用中间高性能内存进行缓冲、缓存和聚合，允许异步操作来隐藏NVM的写入延迟。然而，当我们想要使用NVM作为工作内存时，读取延迟不能轻易缩短。与写入不同，CPU需要在操作之前将数据读取到，这使得异步读取变得不切实际。预读或预取可能有所帮助，但是内存访问应该是完全连续或推测性的。

如图5b所示，PSM直接从Bare-NVDIMM中服务请求，以利用低级别PRAM设备的高读取速度（不像PMEM）。对于写入，PSM采用相同的策略，但为每个PRAM设备使用一个简单的行缓冲区，这是DRAM广泛使用的缓冲区。行缓冲区与系统级缓冲/缓存方案不同，它仅消除多个写入针对特定区域时引入的冲突延迟。在我们的内存子系统的帮助下，CPU仅在面临电源故障时等待写入完成。在我们的架构中，写入通常被视为异步操作，并且它们的延迟可以被容忍。我们直接提供服务的问题是读取针对OCPMEM位置，而写入已经在执行。由于它仅为每个PRAM设备提供单个行缓冲区，处理器可以读取行缓冲区关闭的位置，在并发内存访问中可以观察到这种情况。为了解决这个问题，PSM通过从ECC重新生成目标数据而不是等待之前发出的写入完成来服务读取请求。除了传统的读/写接口外，PSM还公开了缓存转储和内存同步接口，每个接口分别刷新整个缓存空间和行缓冲区。

原型和基准性能。 虽然模拟是验证架构概念和设计的强大工具，但LightPC的目标之一是探索实用的设计，实现无电源故障计算并使之变为现实。不幸的是，内存控制器的工业知识产权(集成在CPU中)被禁止访问和修改。因此，我们将PSM集成到一个基于RISC-V的乱序八核CPU中，并将Bare-NVDIMM连接到我们的定制系统原型中的PSM中。与使用异步接口(DDR-T)的PMEM不同，我们通过传统的同步链路(DDR)连接Bare-NVDIMM，考虑到其确定性延迟特性(暴露给PSM)。图6a和6b分别展示了系统原型和OC-PMEM启用的CPU的实现视图。我们使用六个Bare-NVDIMM和PSM组成OC-PMEM(Figure6a)，八个核心通过系统内存总线直接连接到PSM，无需使用与DRAM相关的组件(Figure6b)。“基准”性能的OC-PMEM启用系统与非持久性的“仅DRAM系统”相比，平均只有12%的差异。我们将在第五和第六节中详细介绍我们的实现和综合分析。

B、软件子系统概述
虽然OC-PMEM提供了数据持久性，并允许主机使用传统的内存接口，但是由多个核心管理的缓存和寄存器存在几个非持久状态（图7a）。我们的PSM可能还有未完全写入BareNVDIMMs的未完成请求。为解决这个问题，我们引入了一种持久性为中心的操作系统（PecOS），提供单个执行持久性切割（EP-cut），使系统可以在不丢失内容的情况下安全地重新执行。单个EP-cut可以消除不必要的缓存刷新和内存同步，同时提供执行持久性。但是，在单个切割中使运行在多个核心上的进程的所有信息持久性是具有挑战性的。例如，即使我们成功转储了所有CPU寄存器并刷新了所有未完成的I/O请求，包括内存、缓存和外设到OC-PMEM，某些进程仍然可以在完全运行出电源失效延迟时间之前进一步更改设备状态。请注意，睡眠进程可能会在短时间内进行调度，从而使机器状态不确定。此外，我们还应该快速以所有同步和一致的方式使多个核心上运行的进程状态持久化，以便可以从EP-cut重新执行它们。

停止和继续（stop and go）。 为了解决这些问题，PecOS采用了停止和继续（SnG）技术，该技术在任何电源事件信号发生时被触发，并在电源失效延迟时间内将非持久状态变为持久状态。如图7b所示，生成EP-cut的所有过程都称为“停止”，从系统应该重新启动的点开始的处理称为“继续”。当电源中断出现时，SnG使所有必要的易失性运行时状态持久化，并确认相应的连接设备在电源保持时间内停止（从中断出现时刻到电源电压下降到其名义值的95%之前的时间段）。为此，SnG首先停止所有进程并锁定它们跨多个核心。在此阶段，SnG访问所有睡眠进程，并通过考虑CPU负载平衡来唤醒它们。由于SnG被限制在核心内，由电源中断调用，称为主控，因此它向分配给处理唤醒进程的其他核心（工作者）发出进程间中断（IPI）。SnG不断迭代此过程，直到没有剩余的睡眠进程为止。与此同时，这些工作者的SnG中断处理程序将刚唤醒的进程重新调度到它们的运行队列中。在此重新调度期间，SnG只是让目标进程让出所有时间，这样它就不能再被调度了。需要注意的是，由于所有核心将具有类似数量的任务，包括正在运行和唤醒的进程，因此可以以系统能够平衡的方式停止这些任务。

一旦它确保了多个核心的不变环境，SnG通过与相应驱动程序协作停止必要的设备和外围设备。接下来，SnG将每个核心的易失性状态转储到OC-PMEM的指定空间。由于某些CPU寄存器甚至对内核不可见，例如IPI、断电和安全寄存器，因此SnG跳转到系统引导加载程序并将所有寄存器存储到OC-PMEM中。同时，主核心发送IPI，使它们逐个下线。在此期间，每个核心转储缓存并暂停，直到缓存刷新完成。最后，系统引导加载程序刷新主核心的缓存并执行内存同步，以确保在使所有核心下线之前没有未完成的请求。

当系统电源恢复时，Stop-and-Go会检查系统初始化请求是否与冷启动或电源恢复有关。如果是后者，SnG会从OC-PMEM中加载系统上下文，并从EP-cut重新执行所有进程。我们将在第四节中详细解释SnG的细节。

离线速度。 我们基于Linux4.19实现了PecOS，并在我们的OC-PMEM系统原型上验证了SnG。我们测试了标准ATX电源供应器和戴尔服务器级电源供应器的实际电源持续时间，结果如图8a所示。为了进行这项评估，我们准备了两个不同的配置，即i）繁忙和ii）空闲。虽然繁忙的配置通过使用重负载线程占用处理器使处理器完全被利用，而空闲是正常运行内核和Shell应用程序的系统。

我们观察到即使处理器被充分利用，标准ATX和服务器电源供应器提供的电源保持时间为22ms和55ms，这比ATX规范声明的保持时间（16ms）要长。尽管SnG有足够的空间，但为了遵守ATX文档的标准时间，SnG被实现为使目标系统持久化，即使在最坏的情况下（16ms）也可以做到。图8b将SnG延迟分解为进程停止、设备停止和离线过程。繁忙和空闲系统的所有内容在8.6∼10.5ms的范围内，比最坏的电源保持时间短46%和34%。SnG验证也在我们在第III-A节中使用的原型上进行。请注意，繁忙系统的用户和内核进程数量分别约为72和48（总共120个进程）。此外，当前的原型包括所有默认设备驱动程序包，反映出过度计算和复杂系统场景。

4、以持久性为中心的操作系统的详细信息
PecOS的EP-cut由两个不同阶段的Stop组成，即i）Drive-to-Idle和ii）Auto-Stop。 Drive-to-Idle使执行环境变为不可变状态，而Auto-Stop则将设备状态转储到OC-PMEM中，清除其缓存和行缓冲区，并完全关闭所有处理器核心。

A. 怠速行驶
所有的运行时和执行状态都在OC-PMEM中，只有一部分在CPU缓存和行缓冲区中。然而，仅通过内存栅栏刷新缓存无法实现执行持久性。尽管SnG不需要检查点或系统镜像，但是一些进程在缓存刷新后仍然可以更新内存状态。这使得易失性内存和非易失性内存不一致，并在系统中所有正在运行的进程中引入执行差异。此外，用户进程甚至在缓存刷新和内存栅栏之后也可以干扰系统需要挂起的设备。例如，如果运行在第二个核心上的用户进程访问SnG正在挂起的设备，则会使系统不确定。

为解决这些挑战，SnG的Drive-to-Idle确保在绘制EP-cut之前，没有进程会进一步更改。当电源事件信号通过中断处理程序触发SnG时，首先抢占该信号的核心成为主核心。在主核心上运行的Drive-to-Idle设置一个原子系统级持久标志，然后遍历从init进程（init_task）派生的活动进程控制块，PCB（task_struct）。在此期间，如图9所示，Drive-to-Idle为用户进程设置一个掩码（TIF_SIGPENDING），同时以平衡的方式分配睡眠任务到不同的核心。主核心随后向每个工作核心发出IPI，以便主侧进程检查可以并行运行，并将刚唤醒的任务驱动到空闲状态。对于用户进程，工作核心向它们发出虚假信号，以便它们可以使用entry assembler（entry.S）从内核模式堆栈处理所有剩余信号。另一方面，Drive-to-Idle执行其他睡眠任务以处理挂起的工作，但它会尽快从关联的运行队列中参考set_tsk_need_resched()将它们的上下文切换出来。每当一个进程被切换出来，Drive-to-Idle将该进程设置为不可中断（TASK_UNINTERRUPTIBLE）并将其从运行队列中移除，以确保该进程无法进一步更改。一旦Drive-to-Idle从运行队列中移除所有任务，它将用空闲任务替换每个工作核心的正在运行的进程。与此同时，每个进程的体系结构状态（包括所有线程的寄存器）都存储在PCB上。

请注意，这些Drive-to-Idle过程在不同的核心上并行执行，并仔细考虑负载平衡。一旦主机准备好将空闲任务放入其运行队列，Drive-to-Idle会向工作者发出信号，并同步所有核心以处于空闲状态。 Drive-to-Idle没有缓存刷新和内存栅栏操作；因此，进入空闲状态（过程停止）的延迟仅占总停止延迟的12％，如我们在图8b中分析的那样。

B、自动停止（Auto-stop）
设备停止。 设备停止。在 Drive-to-Idle 之后，Auto-Stop 禁用设备/外围设备，并将必要的信息存储到设备控制块（DCB）中，如图10所示。由于设备配置基于不同环境而变化，我们利用标准设备电源管理（dpm）机制，同时手动处理外围设备，例如 SPI 和 GPIO。在主核心上，Auto-Stop 访问 dpm_list 中列出的每个设备驱动程序，并调用设备驱动程序实现的已注册的回调函数。dpm 的回调包括一系列电源关闭步骤；第一个回调 dpm_prepare() 防止设备探测从系统级别开始。dpm_suspend() 停止未完成的 I/O 请求，禁用中断并关闭设备。在静止目标之后，它允许通过 dpm_suspend_noirq() 存储设备状态。由于设备之间可能存在依赖关系，因此 SnG 按照 dpm 规定的顺序调用它们。然后，SnG 读取与外围设备相关的内存区域，这些区域并不是物理上位于 OC-PMEM，而是内存映射。Auto-Stop 还将外围设备信息写入 DCB 并刷新主核心的高速缓存。请注意，由于此设备停止需要访问所有设备驱动程序并处理 dpm 回调，因此它是一个耗时的任务，其延迟比 Driveto-Idle 更长。如图8b所示，当所有核心都很忙时，设备停止过程需要占 SnG 端到端延迟的38%。

绘制执行持久性切割。 当PecOS的Go在不同的核心上重新执行所有进程时，PecOS应该适当地控制核心的操作顺序，并知道核心可以在哪个上下文中重新运行。具体来说，在恢复电源的情况下，所有核心都可以通过引用空的执行指针（如内核任务指针和堆栈指针，即__cpu_up_task/stack_pointer）而准备就绪。但是，PecOS的Drive-to-Idle将它们与每个核心的空闲进程关联的地址放在了一起（图11a）。由于所有数据都在LightPC中保持持久性，当Go接管EP-cut时，主机可能会失去操作顺序的控制。因此，Auto-Stop清除了这些内核指针，以便在系统恢复后所有核心都可以同步。每个核心的Auto-Stop然后转储缓存，并通过发出内存栅栏请求确认挂起的内存请求（PSM）已完成。在关机的最后一个过程中（从工作人员的视角），Auto-Stop通知主机它已经准备好离线，并确保所有工作人员都可以安全地关闭电源。由于存在一组不允许从内核访问的寄存器（参见第III-B节），因此在主机完全离线之前需要异常调用。当主机从所有工作人员收到离线报告时，Auto-Stop引发系统级异常以从内核切换上下文到引导加载程序（图11b）。从引导加载程序的角度来看，Auto-Stop以引导加载程序控制块（BCB）的形式将这些寄存器存储到OC-PMEM的保留区域中。为了完成EP-cut的绘制，Auto-Stop还将Go将重新执行系统的返回地址记录为机器异常程序计数器（MEPC）到BCB。当系统再次启动时，需要检查该系统引导是否与SnG或冷启动有关。Auto-Stop清除系统范围的持久标志（由Drive-to-Idle创建），并在此最终阶段进行缓存转储和内存同步的同时向BCB存储提交。由于此阶段是按核心执行并包括多个缓存/内存操作，因此它消耗了大部分SnG延迟。

C、去实现
Go实现了两个阶段的操作，一个是同步多个核心的执行顺序，另一个是重新执行停止的进程，并恢复设备。当电源恢复时，Go作为引导加载程序被加载并检查Stop提交。如果提交存在，Go将BCB（包括引导加载程序和内核相关寄存器）恢复到主控制器中。否则，它将系统控制传递给内核的入口点（start_kernel）。Go还配置中断处理程序，并将主控制器的执行模式提升到最高级别，以便主控制器可以管理所有其他工作器。为了恢复系统，主控制器的Go随后启动所有工作器并重新配置所有寄存器，然后开始停止的进程。此时，工作器不执行任何进程，而是等待通过引用__-cpu_up_task/stack_pointer进行任务分配。主控制器的Go将一个空闲进程放置在OC-PMEM上，指向每个工作器的内核任务指针，并逐个给它们发送IPI。然后，Go通过引用从BCB恢复的MEPC（指示内核端Go应该重新执行的EP-cut）跳转到内核。

接着，主节点的Go根据设备停止时的逆序dpm回调函数来唤醒设备。dpm_resume_noirq()从OC-PMEM中恢复设备状态并允许相应的设备驱动程序接收中断。dpm_resume()和dpm_complete()允许目标设备恢复上下文或重新初始化它们（如果需要）。此外，Go通过从OC-PMEM中读取设备上下文来恢复MMIO区域。所有主节点和工作节点通过恢复虚拟内存空间和刷新TLB来准备好可调度状态。最后，Go首先调度其他内核进程任务，然后调度用户级进程任务，通过检查每个核心的等待队列并将TASK_UNINTERRUPTIBLE更改为TASK_NORMAL。

需要注意的是，由Drive-to-Idle存储的PCB包含了所有执行环境和寄存器，包括页表目录指针。因此，在内核调度器使进程任务运行时，它可以恢复它们并将虚拟地址空间加载到MMU中，进程可以从EP-cut指示的确切点重新执行。

五、开放渠道 PMEM 实施
A、持久支持模块
如图12a所示，OC-PMEM的PSM暴露了写入、读取、刷新和重置端口（对于处理器来说），这些端口在传统的内存总线或交叉开关中很容易实现。在本研究中，由于我们的原型是基于RISC-V架构实现的，因此PSM被集成到了高级可扩展接口(AXI4)中的处理器复杂中，但它也可以集成到其他典型的前端总线，如HyperTransport或直接媒体接口。虽然OC-PMEM旨在使PMEM轻量化，但需要管理长写入和可靠性的缺点。PSM将错误管理和资源冲突解决与裸NVDIMMs相结合。

可靠性管理。 请求的数据直接在处理器缓存和 Bare-NVDIMM 之间传输，没有内部 SRAM/DRAM 缓存，但对于写操作，PSM 对数据进行 ECC 编码，并将它们与原始数据一起存储。PSM 实现了一个简单但高效的磨损平衡算法，受 PRAM 主存储系统中的 Start-Gap 算法的启发而设计。该算法保持对整个 OC-PMEM 范围内服务的写入次数，如果大于一个阈值，磨损平衡器通过与静态随机器一起移动 64 字节块来更新地址空间。对于读操作，PSM 的 ECC 检查数据的正确性，并在数据损坏时返回带有错误包含位的数据（图 12b）。如果检测到包含位，主机会引发机器异常错误（MCE）。根据系统需求，MCE 处理程序可以以各种方式实现，这是我们的未来工作。当前版本的 LightPC 是通过与重置端口交互来重置 OC-PMEM 并重新初始化系统进行冷启动，该端口用于清除所有内存空间。由于缓存刷新和内存栅栏被映射到刷新端口，PSM 根据内存服务引用刷新端口。如果有，PSM 阻止传入请求并确保所有待处理请求均来自 Bare-NVDIMMs，这保证了行缓冲区上没有早期返回请求。

冲突管理。 PSM实现了两个关键组件来解决写操作引起的延迟问题。具体来说，与DRAM相比，在处理器端视角下，PRAM的写操作比读操作慢4-8倍。由于PecOS只在发出缓存刷新或内存栅栏的情况下等待写操作完成，因此写操作的延迟可以大多数情况下被容忍。然而，如果i）向特定区域发出写操作，以及ii）写操作阻塞后续读操作，则长时间的写操作延迟仍然很重要。需要注意的是，PRAM写操作需要长时间的原因是因为PRAM的热核冷却。因此，如果我们保持时间足够长，以使PRAM核稳定（即，尽早返回），PSM就不需要等待完成。然而，覆盖写和读-写后读操作会阻止PSM确保冷却时间。为了解决第一种情况，PSM为每个PRAM设备分配了一个行缓冲区，在本研究中由FPGA的块RAM（BRAM）知识产权实现。行缓冲区分配给处理器刚刚请求的页，如果有以下写操作针对同一页，则可以由行缓冲区聚合并在下一步服务。需要注意的是，第二种情况更为问题，因为大多数应用程序表现出更多的读操作而不是写操作，这种读-写后读操作使早期返回的写操作基本无用。为了解决这个问题，PSM除了目标之外，还从其他媒体读取数据和ECC，并通过重构从其他媒体和ECC中提供请求的数据。这使得PSM可以将读/写操作作为非阻塞服务执行。具体来说，我们使用基于XOR的ECC来最小化加/解密开销。对于每个设备，PSM分配与其输入大小（32B）相同数量的XOR门，并以流水线方式将两个设备输入分为两半进行XOR。同时，如果存在冲突半，那么可以通过这些并行XOR门同时重新生成读取的数据。虽然基于XOR的ECC占用LightPC CPU的2.5%面积，但其加/解密可以在一个周期内执行（因为它是完全组合逻辑），并且它不需要元数据来确定相应的媒体位置（静态映射）。此外，它还用于纠正由大粒度故障引起的错误以及磨损平衡。

B、裸机 PMEM 通道
如图13a所示，可以设计一个类似DRAM的BareDIMM rank。在这种情况下，一个rank内的PRAM设备（通常为8个）通过一个芯片使能（CE）连接。由于DRAM每个设备（bank）的输入粒度为8B，因此一个rank中的所有DRAM可以并行提供64B的cacheline服务。这种类DRAM的NVDIMM设计可以与DRAM一起很好地工作，因为一个rank（8B * 8）可以提供64B大小的cacheline请求，并且如果有更多请求，可以通过不同的rank，即跨DIMM并行性来处理。虽然我们猜测新出现的Optane DIMM采用类DRAM的NVDIMM设计来提高内存并行性，但遗憾的是它们无法有效地处理基于PRAM的工作内存。由于PRAM每个设备的输入粒度比DRAM大（32B），如果我们为Bare-NVDIMM实现类DRAM的通道，则默认访问大小变为256B（与PMEM DIMM相同）。因此，需要进行读取和修改以弥合cacheline和DIMM之间不同访问粒度造成的差异。由于类DRAM通道需要在每个rank中启用所有PRAM设备，因此64B cacheline大小的请求会浪费许多PRAM资源，从而导致更多的传入请求被挂起。

考虑到我们的一个目标（尽可能多地去除易失性资源），我们采用双通道设计来实现Bare-NVDIMM，即将每两个PRAM设备分组，并共享每个组的CE。与DRAM Bare-NVDIMM设计相比，我们的Bare-NVDIMM与最后一级缓存操作非常协调。具体而言，如图13b所示，64B缓存行大小的请求会立即由双通道PRAM（32B * 2）服务，而其余的PRAM设备则可以承担进入的内存请求。因此，顺序访问可以利用在一个等级内的PRAM设备之间交错请求的优势（intraDIMM并行），同时保持跨等级边界的内存访问（随机访问）与DRAM-like DIMM设计类似地交错。

六、评估
方法。 我们将原型的内存子系统配置为三个选项：i）LegacyPC，ii）LightPCB和iii）LightPC。这三个选项具有与OC-PMEM相同的计算复杂度，但LegacyPC另外采用DRAM作为混合设计。LegacyPC由Linux4.19管理，该管理器将所有进程和数据结构存储在DRAM中。作为我们实现的基准，LightPCB将所有进程和数据放置在OC-PMEM上，但它处理类似于传统内存控制器的写后读。另一方面，LightPC实现了所有高级PRAM管理方案，例如早期返回写入和数据重建，以实现非阻塞服务（参见第V-A节）。请注意，尽管LightPC的PRAM地址空间是LegacyPC的工作内存（DRAM）的2倍，但为了更好地进行比较，我们将所有Linux和应用程序配置为在LegacyPC的内存空间中运行（即没有由进程引起的分页和交换内存）。

为了进行执行持久性分析，我们实现了四个正交的持久性机制：i) SnG，ii) 系统镜像，iii) 应用程序级检查点恢复，和 iv) 系统级检查点恢复。SnG是与LightPCB和LightPC一起实现的，而其他三种机制是在LegacyPC中实现的，分别称为SysPC，A-CheckPC和S-CheckPC。SysPC在存在休眠信号的情况下将非持久性数据和执行状态存储到OC-PMEM中。我们基于分布式多线程HPC检查点技术实现的A-CheckPC选择性地在每个函数的结尾存储堆栈和堆变量，而S-CheckPC是基于Berkeley实验室HPC检查点/恢复(BLCR)实现的，它每秒在内核级别定期转储目标线程的虚拟内存结构。与SysPC相比，A-CheckPC和S-CheckPC对于电源故障更具容错能力。上述平台的重要特征在表格I中有解释。

基准测试、功耗和崩溃控制。 我们选择了五个HPC应用程序；两个用于HPC密钥基础设施的加密算法（AES / SHA），以及三个用于并行编程代理应用程序估计（miniFE / SNAP）和并行代数多重网格求解器（AMG）[38-40]。我们还选择了来自SPEC2006的八个数据密集型应用程序，并评估了Redis、KeyDB、Memcached和SQLite等内存密集型应用程序。

为了使这些应用程序在我们的硬件原型上运行，我们基于RISC-V ISA对它们进行了移植和重新实现。我们使用多线程执行HPC和内存数据库工作负载，而Crypto和SPEC则使用单线程进行评估，因为它们的基准特性。请注意，所有工作负载都在我们已经运行数十个内核线程的系统上执行。在表II中分析了重要的行为，例如负载/存储比和内存访问行为。当关闭电源时，大多数FPGA会失去其硬件编程文件（即位文件）。我们的自定义板子不使用已下载的位文件，而是将存储器配置（.mcs）存储到板载ROM中，并在引导时自动恢复硬件编程。对于断电测试，我们从电源供应器中物理拆除交流电源。

尽管FPGA的频率较慢（400MHz），但我们的Synopsys前端和后端模拟显示，我们的八核外存处理器原型的RTL能够成功在1.6GHz的速度下运行。需要注意的是，真实的应用程序不是内存压力测试工具。应用程序的内存延迟效应在测试频率下不会减弱。为了确保这一点，我们选择了两个内存密集型应用程序，并将服务器Intel Xeon八核处理器的频率从0.8 GHz扩展到1.8 GHz。虽然DRAM的工作频率为2.4GHz，但用户在不同频率下的体验（以内存停顿为单位）显示出类似的趋势。

A、非持久计算性能
使用OC-PMEM作为主要工作内存的潜在问题可能是性能下降，与仅使用DRAM的系统相比。我们通过比较仅使用DRAM的LegacyPC和使用LightPC-B/LightPC的系统来分析应用程序延迟和功率/能量行为。

内存执行延迟。 图15比较了OC-PMEM和DRAM仅用情况下用户级应用程序的执行时间。尽管PRAM的读写延迟比DRAM分别慢了1.1倍和4.1倍，但每个基准测试的完成时间并没有太大的差异；总体上，LightPC比LegacyPC慢了仅12％。我们认为有两个根本原因。首先，DRAM速度（频率）本身与应用程序级性能并不严格相关，但内存级资源冲突是决定用户体验的更重要的参数，这也是的观察到的。其次，PRAM的写入惩罚相对显着，但是，大多数本质上在负载存储体系结构上的应用程序显示出比存储更多的负载。对于我们测试的工作负载，平均负载数比存储数多27倍（表II）。考虑到LightPC带来的好处（在持久性，功率和能量方面，稍后将进行解释），我们认为内存执行的12％慢应用程序级延迟在许多用途中是可以容忍的。

通过比较LightPC和其基线（LightPC-B），我们可以详细估算我们的PSM可以提高多少用户体验。如图所示，LightPC在我们测试的所有工作负载中表现出平均执行时间缩短了2.8倍。对于SNAP和astar应用程序，特别是LightPC的性能比其基线平均提高了4.1倍。这是因为内存写请求的数量大于任何其他应用程序（超过几百万条指令），而这些应用程序表现出大量的读取（比写入多2.7倍）。相比之下，对于SHA（SHA512），LightPC的性能提高是有限的。这是因为尽管SHA的读取比例高于上述两个应用程序，但SHA表现出的写入请求数量比我们测试的所有应用程序都少。

去除头部阻塞。 为了更深入地分析PSM非阻塞服务在内存级别的性能提升，我们进一步分析了LightPC-B的低级读取延迟在整个应用程序执行期间相对于LightPC的归一化情况（如图16所示）。从这个图中可以看出，与基线读取延迟相比，LightPC的性能提升范围从7倍到14.8倍不等。特别是，LightPC平均提高了wrf（天气预报模型）的内存级读取性能14.8倍。由于wrf递归地使用预测历史记录进行下一次预测，它会引入许多读取操作，前往wrf在之前步骤中写入的位置。这种应用行为展现了许多头部阻塞问题，可以通过LightPC解决。另一方面，与其他应用程序相比，mcf的性能提升相对较少。由于写入的数量明显小于读取的数量，mcf读取刚刚写入的数据的机会比其他工作负载要少。

总体而言，平均减少9倍的读取延迟是改善我们测试的所有应用程序中用户体验的关键所在。需要注意的是，相对于写入数据可以异步写入底层内存，下一个指令应该等待数据到达，因此读取比写入更为重要。LightPC和LightPCB之间巨大的读取延迟差异的原因是长时间的写入延迟服务于同一内存位置。由于LightPC-B没有采用非阻塞服务机制，这样的读-写请求都被挂起，从而导致了头部阻塞问题。相反，LightPC不会阻塞任何指令以等待写入完成，而是通过使用其他侧面内存银行的数据与ECC构建新数据来直接服务读取。

可能的内存带宽影响。 考虑到用户关注带宽，我们还评估了一个用于测量LegacyPC和LightPC可持续内存带宽的合成基准测试(STREAM)。如图17所示，通过将LightPC的结果归一化为LegacyPC的结果，分析了目标平台的内存层次结构带宽。虽然LightPC的内存级带宽行为略逊于其应用程序执行时间的特征，但LegacyPC和LightPC之间的带宽差异仍在合理的范围内（平均为78%）。这是因为STREAM在合成基准测试中将数据从一个位置移动到另一个位置，从而减少了缓存的影响，并使得（非缓存）写入超过真实世界工作负载的读取。具体而言，与我们测试的真实世界工作负载相比（参见表reftab: bench），它们的平均缓存命中率和读取比例分别降低了5%和94%。需要注意的是，由于Add和Triad对两个以上的数组进行逐元素操作，它们比Copy和Scale（将一个数组复制到另一个数组）更接近于LegacyPC，因此具有更多的读取操作。

功率和能量。 图18显示了我们针对上述内存执行测试的平台的功率和能量值；功率值嵌入在图的左上角。平均而言，LightPC和LightPC-B仅消耗LegacyPC总系统功率的28％。具体而言，LegacyPC消耗18.9瓦特，而LightPC和LightPC-B仅消耗5.3瓦特。这是因为PRAM本身的功耗低于DRAM，但更重要的是，LightPC没有管理DRAM刷新和系统功率的负担。

尽管LightPC和LightPC-B的功耗行为相似，但与LegacyPC相比，LightPC-B仅将能量降低了8.2％。这是因为读取后写入和长写入延迟使应用程序执行时间变长（正如我们所讨论的），从而失去了OC-MEM带来的收益。另一方面，LightPC的能效比LegacyPC整体高69％。尽管LegacyPC和LightPC之间的执行完成时间差异在一个合理的范围内（平均12％），但LightPC的功耗行为比LegacyPC高出73％，为不需要挥发性缓冲区和外部存储的节能计算环境提供了支持。

B、持久计算的性能
图19a、19b和19c展示了SysPC、A-CheckPC和S-CheckPC在执行带电源关闭的基准测试时相对于LightPC的性能，同时将执行周期分解为基准测试执行和持久性控制两部分。对于所有基准测试套件，A-CheckPC的执行延迟都超过了134B个周期，而SysPC的平均执行延迟仅为60B个周期。这是因为，尽管A-CheckPC选择性地转储每个函数使用的堆栈和堆变量，但它在执行期间经常将数据从DRAM迁移到OC-PMEM，因此在每个检查点的提交完成之前，A-CheckPC的基准测试执行通常会被阻塞。虽然系统映像的大小比A-CheckPC的映像要大得多，但SysPC的延迟平均缩短了5.5倍。这是因为SysPC只在一次性（在断电时）转储系统映像，而A-CheckPC在每个函数调用时保存检查点映像。请注意，我们的A-CheckPC的检查点粒度比其他检查点重启技术（如自适应动态检查点）要粗糙得多，但A-CheckPC展现出了如此显著的开销。虽然S-CheckPC不能像用户想要的那样完全控制执行持久性，但它以自我管理的方式定期转储数据，可以减轻ACheckPC持久性控制的开销。如图19所示，通过自动将应用程序的虚拟内存空间通过vm_area_struct转储到OC-PMEM，SCheckPC平均减少了A-CheckPC的执行延迟73%。特别是在加密方面，SCheckPC的好处就在于它只是简单地转储应用程序的虚拟内存，而不需要理解每个加密/解密上下文。尽管如此，SCheckPC的延迟平均仍比SysPC差52%。这是因为SysPC只有在发生断电时才会将映像存储回OC-PMEM。

相比之下，当我们将持久性视为首要任务时，LightPC的执行延迟比SysPC、A-CheckPC和S-CheckPC分别缩短了1.6倍、8.8倍和2.4倍。这是因为PecOS的SnG平均只占总执行时间的0.3%。图20显示了SysPC和S-CheckPC的刷新延迟。该图还包括我们测量得到的ATX和Server的断电残留储能（保持时间）（参见图8）。相较于ATX/Server的保持时间，SysPC需要花费172倍和112倍的刷新延迟。S-CheckPC需要周期性地将虚拟内存数据转储到OC-PMEM，其刷新操作分别比ATX/Server的保持时间长3.5倍和1.4倍。相反，LightPC的Stop成功地在12.8毫秒内刷新了未完成的请求，这比ATX/Server的保持时间短了33%和21%。


C、一致性控制效率和可扩展性
性能。 图21a显示了LightPC、SysPC和A / S-CheckPC的动态IPC的时间序列分析。它还将每个一致性控制步骤分解为周期数（x轴）。 LightPC的Stop在关机时消耗了1900万个周期（mc），并需要在持久性截断之前12.8mc。由于LightPC的Stop的延迟比最坏情况的电源失效延迟短20％，平均而言，这使得LightPC成功实现完全一致。相比之下，SysPC需要70亿个周期（bc）将系统镜像存储到OC-PMEM中，即使在电源恢复之后，SysPC也需要花费4.2bc来加载系统镜像，这比LightPC的Go慢358倍。 A / S-CheckPC不需要时间来准备系统镜像，因为它们会定期转储必要信息。请注意，由于定期转储，它们在断电/上电时间的性能行为彼此相似。但是，由于这两个的检查点过程会消耗内存带宽并进行内存同步/刷新，因此A / S-CheckPC可能会对基准测试执行造成负担。由于A / S-CheckPC无法转储内核本身和机器模式寄存器，因此一旦电源恢复，不可避免地需要冷启动。因此，在基准测试恢复之前，它们在电源恢复后显示IPC峰值。请注意，SysPC、A-CheckPC、S-CheckPC和LightPC的关机准备过程的平均IPC分别为0.5、0.23、0.30和0.66，而它们的上电恢复IPC分别为0.59、0.23、0.19和0.64。由于LightPC没有与内存转储相关的线程挂起，因此LightPC的SnG比电源失效延迟更快。

功耗/能效。 图21b显示了系统在关机准备和开机恢复过程中的动态功耗值。考虑到执行周期（x轴），这张图也可用于能量分析。SysPC消耗20瓦特将系统休眠，不幸的是，即使在断电延迟（直到7bc）之后，它仍需要持续的电力（和19.7焦耳）来完成系统镜像转储。相比之下，LightPC通过19mc让核心和设备离线，完成Stop需要消耗4.5瓦特和53毫焦耳。A / S-CheckPC的功耗行为类似于SysPC，但它们可以在断电时间结束时关闭系统，因为每个检查点都可以用作已提交的执行事务。在电源恢复时，所有持久性机制的功耗和能量行为均相似，因为它们都必须重新启动系统。由于加载系统镜像比冷启动轻，因此SysPC的功耗比A / S-CheckPC少2.7％。相反，Go通过12.8mc以4.4W恢复所有进程，从而消耗52mJ。

可扩展性分析。 Figure22分析了当考虑到最坏情况的配置时，即将PecOS的内核列表dpm_list（730）中的最大数量的驱动程序，以及使所有缓存行完全脏化从而刷新整个缓存时，LightPC可以支持的可扩展性。由于当前原型由于FPGA面积限制，不幸地无法容纳超过8个物理核心，因此我们估计了存在超过8个核心的情况下的SnG延迟。为了进行准确的估计，我们使用不同的缓存大小修改LightPC，并为每个核心进行硬件仪器测量，以测量每个核心的下线，缓存刷新和驱动程序/进程暂停的最坏情况延迟。如图所示，在具有40MB缓存的64个核心的机器上，SnG可以成功地停止机器，同时满足服务器PSU的电源保持时间（cf.55ms，第III-B节）。我们认为这种多核机器将利用服务器PSU而不是ATX文档值（16ms）。但是，如果将机器调节为满足16ms，那么在这种最坏情况下，SnG可以停止具有16KB缓存的最多32个核心。

七、相关工作
非易失性处理器用于能量收集。 由于持久性保证是非易失性计算的关键，因此存在许多处理持久性控制的研究[23, 31, 71–75]，以及针对PRAM的重要分析。提出了非易失性处理器(NVPs)[72–74]，用于使能量收集系统耐受功率变化。NVPs定期将寄存器文件、流水线锁存器和程序计数器转储到FeRAM中，或将它们全部替换为FeRAM。NVPs是一种基于仿真的研究，旨在探索设计空间，以使低功率处理器具有持久性。然而，NVPs无法使系统完全持久。它们不考虑堆栈内存的一致性控制，因为目标系统处于能量收集环境中。

整个系统的持久性。 整系统持久性（Whole-system persistence，WSP）提出了一种基于闪存备份的故障刷新方案，利用超级电容器将缓存和DRAM数据转储到底层闪存。这个转储过程类似于休眠，但可以由DIMM侧控制器执行，这可能需要长时间（最多10秒）。虽然超级电容器可以保证内存级别的持久性，但它具有几个限制。首先，如果在某个时期连续发生电源故障，则使用它们的持久性可能会崩溃。这是因为超级电容器也需要可靠的充电时间，这与转储时间（10秒）类似。如果在充电时间内连续发生电源故障，则不能捕获充电时间所做的状态更改。其次，基于闪存备份的解决方案不具有可扩展性，由于超级电容器缩放问题，其内存容量甚至受限于DRAM；WSP的容量可能小于（或等于）DRAM。WSP还需要复杂的BIOS配置和校准过程。因此，它仅在仿真环境下进行单线程闭环测试。

增强型异步DRAM刷新。 最近，英特尔提出了eADR，在电源事件信号触发时将缓存数据刷新到PMEM。这个过程类似于Stop（在其结束时执行刷新操作）的一部分。然而，它需要确保使系统状态一致/持久，按照特定顺序（即EP-cut）下线设备驱动程序和核心，以便系统在恢复电源时能够恢复所有进程/设备上下文和寄存器。请注意，由于eADR缺乏对一致系统状态的控制，缓存行在没有EP-cut的情况下刷新其缓存时也可能发生更改并变为脏数据。

八、对未来工作的一个讨论
写入耐久性和可靠性。 我们PRAM设备的写入耐久性（设置和重置循环）在10⁶∼ 10⁹ 的范围内，与大多数先前的PRAM研究报告相同。不幸的是，这个数值比DRAM差一个数量级，因此，裸NVDIMM本身不能满足DRAM提供的同样可靠性水平。因此，LightPC可能不是专门用于大量写入数据而没有读取（例如突发缓存）的应用程序的正确设计选择。然而，由于两个原因，本研究仍然适用于PRAM作为工作内存：i）读取比写入更敏感；ii）PRAM在破坏性读取和刷新时没有写入。正如在第VI节中分析的那样，加载指令通常比存储指令更常见。我们相信，大多数自然的指令集都有更多的操作数来读取内存（输入）而不是写入（输出）。在设备级别上，读取更频繁且更敏感；几层芯片存储（寄存器、L1 / L2等）可以吸收存储指令的写入，而读取大多数情况下不能。请注意，DRAM由于其破坏性读取的特性必须为读取和写入的输入/输出数据进行写入。DRAM还必须每64ms将现有数据写回以避免由泄漏电流引起的数据丢失。由于PRAM的写入都不会受到破坏性读取和刷新的影响，使用写入耐久性进行直接比较可能不公平。

需要注意的是，还有一些研究期望通过提高写入耐久性达到10¹² ∼ 10¹³的水平，这与DRAM的耐久性相似或略低（例如，10¹⁴∼10¹⁶）。例如，使用薄的金属线性和有限孔隙的单元结构，以减少设置/复位开关的不可用性，从而显着提高了写入的耐久性。[87-89]还研究了PRAM的写入干扰问题，包括热串扰，通过增加热边界电阻和分离物理单元来增强写入耐久循环。

错误率和覆盖率。 本文中，我们假设我们基于XOR的ECC（XCC）可以管理低于10^-19的不可纠正比特错误率（UBER），这与大多数存储级内存所假设的UBER相似。具体而言，本文的假设是，在给定时间内，两个Bare-NVDIMM中的所有PRAM模块不会同时死亡。考虑到写入寿命范围从10⁶到10⁹不等，有一项研究表明，支持10^-19 UBER PRAM需要8位纠错能力（每个缓存行）。虽然这种ECC覆盖要求比大多数DRAM使用的chipkill或double chipkill ECC更强[94-96]，但LightPC的XCC的纠错能力比8位纠错高得多。如V-A节所述，XCC能够重建缓存行一半数据的冲突，每个缓存行可以恢复32B数据。为了使Bare-NVDIMM更加健壮，我们可以使用更细粒度的基于符号的ECC[97-100]作为补充，但这可能会增加Bare-NVDIMM的访问延迟，因为需要进行加/解密。在这种未来的方法中，可以仅在两个或更多Bare-NVDIMM同时死亡的情况下使用基于符号的ECC，而在大多数情况下使用XCC，以尝试利用两种ECC方案的优点。

磨损平衡能力。 LightPC利用StartGap作为PRAM工作内存的一种简单而有效的磨损平衡方法。这种磨损平衡方法的主要思想是通过对Bare-NVDIMM的整个内存地址空间进行随机移动（shifting），而不是维护逻辑地址和物理地址之间的映射信息。正如在第V-A节中所解释的那样，这种地址随机移动可以通过静态随机化地址并在每个给定的写入次数（默认为100）时在地址空间中移动一个64字节的块来简单地完成。因此，磨损平衡器的元数据寄存器仅与起始/间隔偏移量、写入阈值计数器和静态随机器的种子相关联。LightPC将这些寄存器（每4TB∼6TB内存不到64B）与其他易失性状态一起存储在SnG的EP-cut中。当系统恢复电源时，元数据作为EP-cut信息的一部分被恢复，使得我们的磨损平衡器可以跨系统启动使用。

虽然这种轻量级元数据和磨损平衡管理是具有成本效益的，但存在限制。假设有一个异常应用程序，不断访问一组特定地址而不生成任何其他写入。在这种情况下，我们的磨损平衡器无法在PRAM的所有不同位置均匀分布写入。这是因为每个时期只从内存空间的末尾（由间隙寄存器指示）依次移动64字节块。虽然已经证明了使用StartGap的地址移位的静态随机化可以提供理论最大寿命的97％，但我们认为它仍然容易受到这种恶意访问模式的攻击。我们考虑在未来的工作中定期更改种子寄存器的值，从而提高耐久性水平。

九、总结
我们提出了LightPC，通过从内存层次结构和持久性控制中删除所有与DRAM相关的硬件组件和软件堆栈，保证了数据和执行的持久性。我们的非易失性计算板原型在28纳米FPGA上实现了多个核心和持久性子系统，提供了用户级性能，类似于仅使用DRAM的系统，同时消耗的功率比检查点恢复低73％，各种基准测试的延迟缩短平均为8.8倍。

致谢和引用省略……