ArchTM: Architecture-Aware, High Performance Transaction for Persistent Memory
Introduction
崩溃一致性一直是使用PM的一个问题，PM的掉电不丢失可以让程序在崩溃后恢复在PM中的数据，但是这个恢复需要一致性的保证。现有的崩溃一致性机制主要分为三种：redo-logging, undo-logging, CoW-based designs.
之前的工作都主要聚焦在减少PM的数据拷贝和降低持久化的开销，但是都忽略了傲腾内存PM的本身特性，把PM当成性能稍差的DRAM。然而，实际上并不是如此，PM的本身mirco architecture（例如256 byte buffer）对于事务的性能影响非常大。
所以事务的设计需要考虑以下原则：
- 避免小写（小于256字节的）
- 尽可能的连续写
基于以上原则，本文提出了一种类似于CoW（copy-on-write）的机制去避免日志的双写问题，同时将内存分配器和对象的元数据保存在DRAM上，避免对PM的小写。但是，DRAM并非是持久性的，这会导致崩溃一致性的问题，ArchTM将元数据和事务ID保存在数据头中，一起持久化，在崩溃恢复中降低开销。同时，为了增加连续写的机会，ArchTM更改了内存分配器，尽可能的分配连续的内存。
Background
PM transcation
failure-atomic事务一直是解决崩溃一致性的主要思路。使用failure- atomic机制，无论事务成功与否，数据都会写入PM。实现这个机制主要有两种模式，log and Cow（copy on write）。
- undo-logging
- redo-logging
- copy on write
PM内存管理
PM中的持久性对内存管理提出了一致性和低碎片化的独特要求。当下的内存分配器分别维护了两个空闲链表，一个是线程的空闲链表，另一个是全局的空闲链表。对于内存的分配和回收都是优先使用线程的空闲链表，这就会导致碎片话的问题。
PM结构
现有的CPU和cache的传输的粒度是cache line（64B），但是PM存在里面的事务粒度是256B，这种粒度的不匹配，导致更新一个缓存行（64B）可能导致导致在Optane介质内进行256B的写入。
PM性能特征
事务性能特征
- 事务大部分的开销在于日志更新或元数据更新上
- 超过78%的持久化对象小于64字节，也就是说，PM上有很多小的写操作
- 所有的系统都出现了写放大，使PM的写流量增加了1.8倍-27倍。
- 基于CoW的系统比基于日志的系统有更多的元数据更新。
PM写性能特征
上图显示了PM和DRAM的顺序、随机写带宽差距，当粒度为64B时，PM的随机写带宽只有顺序写带宽的25%，这个就是由于之前说的256B的PM内部粒度造成的。