Asynchronous Persistence with ASAP

TL;DR

ASAP introduces a hardware logging approach that enables asynchronous commitment of atomic regions in persistent memory, reducing latency while maintaining data consistency through hardware-enforced dependency tracking.

Contribution

It proposes a novel hardware solution that allows asynchronous commit of atomic regions, addressing latency issues in persistent memory logging.

Findings

Reduces commit latency for atomic regions in persistent memory

Ensures correct commit order through hardware dependency enforcement

Improves overall performance of persistent memory operations

Abstract

Supporting atomic durability of updates for persistent memories is typically achieved with Write-Ahead Logging (WAL). WAL flushes log entries to persistent memory before making the actual data persistent to ensure that a consistent state can be recovered if a crash occurs. Performing WAL in hardware is attractive because it makes most aspects of log management transparent to software, and it completes log persist operations (LPs) and data persist operations (DPs) in the background, overlapping them with the execution of other instructions. Prior hardware logging solutions commit atomic regions synchronously. Once the end of a region is reached, all outstanding persist operations required for the region to commit must be completed before instruction execution may proceed. For undo logging, LPs and DPs are both performed synchronously to ensure that the region commits synchronously. For redo logging, DPs can be performed asynchronously, but LPs are performed synchronously to ensure that the region commits synchronously. In both cases, waiting for synchronous persist operations (LP or DP) at the end of an atomic region causes atomic regions to incur high latency. To tackle this limitation, we propose ASAP, a hardware logging solution that allows atomic regions to commit asynchronously. That is, once the end of an atomic region is reached, instruction execution may proceed without waiting for outstanding persist operations to complete. As such, both LPs and DPs can be performed asynchronously. The challenge with allowing atomic regions to commit asynchronously is that it can lead to control and data dependence violations in the commit order of the atomic regions, leaving data in an unrecoverable state in case of a crash. To address this issue, ASAP tracks and enforces control and data dependencies between atomic regions in hardware to ensure that the regions commit in the proper order.

Full text

Asynchronous Persistence with ASAP

Ahmed Abulila

Microsoft Corporation

, 

Izzat El Hajj

American University of Beirut

, 

Myoungsoo Jung

Korea Advanced Institute of Science and Technology

 and 

Nam Sung Kim

University of Illinois at Urbana-Champaign

1. Motivation

The problem our work tackles is hardware logging for persistent memory. It is important because it promises higher performance than pure software solutions.

Persistent memory provides the byte-addressability and low latency of DRAM as well as the persistency of storage devices. Programming persistent data structures typically involves writing atomic regions that are atomic and durable, ensuring that stores to persistent memory within an atomic region persist in an all-or-none manner. To guarantee the atomicity and durability of atomic regions, Write-Ahead Logging (WAL) has commonly been used (lognvmm, ). WAL consists of two key persist operations: log persist (LPO) and data persist (DPO) (aries, ). LPO operations flush log entries to persistent memory before making the data persistent, to ensure that a consistent state can be recovered if a crash occurs before all the data of a given atomic region has persisted. DPO operations write back the actual data modified by the atomic region to persistent memory.

Software logging solutions (mnemosyne, ) for persistent memory offload the complexity of managing logs to the software, placing persist operations on the critical path of an atomic region’s execution. In contrast, hardware logging solutions (ReDU, ; proteus, ) for persistent memory can initiate persist operations in a manner that is transparent to software, and can complete these operations in the background, overlapping them with the execution of other instructions and ultimately resulting in better performance.

2. Limitations of the State of the Art

The key limitation of state-of-the-art hardware solutions is that hardware undo logging solutions do not support asynchronous persist operations, whereas hardware redo logging solutions support asynchronous data persist operations but not asynchronous log persist operations.

Persist operations that are overlapped with execution of other instructions can be classified as synchronous or asynchronous with respect to the end of an atomic region. Synchronous persist operations are overlapped with execution of other instructions within an atomic region, but once the end of an atomic region is reached, all persist operations initiated by the atomic region must complete before instruction execution proceeds. In contrast, asynchronous persist operations are also overlapped with instructions that are executed after the atomic region, hence allowing instruction execution to proceed past the end of an atomic region without waiting for persist operations to complete.

The advantage of asynchronous persist operations is that they reduce idle time by not waiting at the end of an atomic region. Moreover, in a multi-threaded context, if the atomic region is nested inside a critical section to guarantee isolation, the latency of asynchronous persist operations will not be part of the critical section (PMEMSpec, ). Removing the persistence latency from critical sections benefits concurrency by reducing the execution time of critical sections.

The two major approaches to hardware WAL are undo-logging (proteus, ) and redo-logging (ReDU, ). While undo logging has several advantages over redo logging which are discussed in the paper, a key disadvantage is that hardware solutions for undo logging do not support asynchronous DPO operations, whereas hardware solutions for redo logging do. Neither support asynchronous LPO operations.

3. Key Insights

The key insight in the paper is that asynchronous log and data persist operations can both be supported under undo logging if control and data dependences between atomic regions are tracked and enforced.

The challenge with supporting asynchronous persist operations under undo logging is that allowing instruction execution to proceed past the end of an atomic region before the atomic region has completed its persist operations may result in violating control and data dependencies between atomic regions. In other words, it runs the risk of a later atomic region committing before an earlier one does, or, in a multi-threaded context, a consumer atomic region committing before the corresponding producer atomic region does (DATM, ). These situations leave the data in an unrecoverable state after a crash. The paper includes examples that demonstrate these situations.

We show that asynchronous LPO and asynchronous DPO operations can both be supported under undo logging by tracking control and data dependences between atomic regions and enforcing atomic regions commit (undo logs are freed) in a manner that respects these dependences.

4. Main Artifacts

The main artifact presented in the paper is a hardware design that supports undo logging with asynchronous log and data persist operations by tracking and enforcing control and data dependencies between atomic regions in hardware.

The paper presents ASAP, the first Architecture Support for Asynchronous Persistence (ASAP). ASAP allows both LPO and DPO operations to happen asynchronously, and tracks control and data dependencies between atomic regions in hardware to ensure that atomic regions commit (undo logs are freed) in the proper order. The hardware extensions that ASAP requires are shown in Figure 1. The key extensions include:

• •

Per-thread registers (❶) assist with log management

• •

Structures to track which atomic region last modified a persistent cache line to help capture data dependecies between atomic regions (❷)

• •

Structures to track which cache lines have been modified by an atomic region to ensure that all the cache lines persist before the atomic region commits (❸)

• •

Structures to track which atomic regions are still active and the atomic regions they depend on to ensure that all an atomic region’s dependencies have been resolved before its log is freed (❹)

ASAP provides a simpler software interface than prior hardware undo logging approaches. Also, ASAP applies three key optimizations to reduce persistent memory traffic: LPO dropping, DPO coalescing, and DPO dropping. These optimizations are particularly effective in combination with asynchronous persist operations in reducing memory traffic. ASAP is implemented and evaluated using gem5.

5. Key Results and Contributions

We show that ASAP improves performance compared to state-of-the-art hardware logging approaches that perform some persist operations synchronously.

We compare ASAP to the following baselines:

• •

SW: Software-only implementation of undo-logging

• •

HWUndo: Based on the state-of-the-art hardware undo logging implementation (proteus, ) which performs LPO and DPO operations synchronously

• •

HWRedo: Based on the state-of-the-art hardware redo logging implementation (ReDU, ) which performs LPO operations synchronously

• •

NP: Data is read from and written to persistent memory, but no crash consistency is guaranteed

The performance improvement for select benchmarks is shown in Figure 2. More benchmarks are evaluated in the paper. ASAP improves performance compared to state-of-the-art hardware undo logging by 1.41$\times$ (geomean), while achieving 0.96$\times$ (geomean) of the ideal performance when no persistence is enforced. ASAP also reduces persistent memory traffic, generating 0.52$\times$ (geomean) the traffic generated by state-of-the-art hardware undo logging techniques. ASAP is robust against increasing persistent memory latency, and is therefore suitable for both fast and slow persistent memory technologies.

6. Conclusions

This paper presents ASAP, a hardware logging scheme that allows atomic regions to commit asynchronously. Committing atomic regions asynchronously removes the need to wait for log persist and/or data persist operations at the end of atomic regions, which reduces the latency of these regions. To ensure that the atomic regions commit in the proper order, ASAP tracks and enforces control and data dependencies between atomic regions in hardware. Our evaluation shows that ASAP outperforms state-of-the-art hardware undo and redo logging techniques, which commit atomic regions synchronously. It also reduces persistent memory traffic and is suitable for both fast and slow persistent memory technologies.