Distributed Logless Atomic Durability with Persistent Memory

Gupta, Siddharth; Daglis, Alexandros; Falsafi, Babak

doi:10.1145/3352460.3358321

Cited by 26 publications

(16 citation statements)

References 34 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The inclusion of the ThreadID in the RID removes the need to synchronize across threads when assigning atomic region IDs [23].…”

Section: Representing the Atomic Region Idmentioning

confidence: 99%

“…On-Chip Data Versioning: Several works use on-chip resources to contain partial updates on-chip until an atomic region completes [1,6,7,23,31,43,74], after which the updates are synchronously committed to persistent memory before proceeding past the end of the atomic region. For example, Kiln [74] has a nonvolatile last-level cache to preserve partially updated data.…”

Section: Related Workmentioning

confidence: 99%

“…Lai et al [43] adds a separate non-volatile on-chip structure to avoid complex modifications to the cache hierarchy. LAD [23] avoids adding a new on-chip structure by exploiting the WPQ in the memory controller which is considered part of the persistence domain. BBB [5] has proposed a battery-backed buffers in the CPU to bring the point of persistency closer to the CPU.…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Asap

Abulila

Hajj

Kim

2022

Proceedings of the 49th Annual International Symposium on Computer Architecture

View full text Add to dashboard Cite

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 (LPOs) and data persist operations (DPOs) in the background, overlapping them with the execution of other instructions.Prior hardware logging solutions commit atomic regions synchronously. That is, once the end of a region is reached, all outstanding persist operations required for the region to commit must complete before instruction execution may proceed. For undo logging, LPOs and DPOs are both performed synchronously to ensure that the region commits synchronously. For redo logging, DPOs can be performed asynchronously, but LPOs are performed synchronously to ensure that the region commits synchronously. In both cases, waiting for synchronous persist operations (LPO or DPO) 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 LPOs and DPOs 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.Our evaluation shows that ASAP outperforms the state-of-theart hardware undo and redo logging techniques by 1.41× and 1.53×, respectively, while achieving 0.96× the ideal performance when no persistence is enforced, at a small hardware cost (< 3%). ASAP also reduces memory traffic to persistent memory by 38% and 48%, * Ahmed Abulila is currently affiliated with Microsoft Corporation.

show abstract

“…The inclusion of the ThreadID in the RID removes the need to synchronize across threads when assigning atomic region IDs [23].…”

Section: Representing the Atomic Region Idmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Asap

Abulila

Hajj

Kim

2022

Proceedings of the 49th Annual International Symposium on Computer Architecture

View full text Add to dashboard Cite

show abstract

“…In particular, all stores in a region should become persistent in an all-or-nothing-based manner before the next region persists, allowing programs to restart from the beginning of the interrupt region after failure recovery. For this purpose, Capri supports two-phase atomic stores similar to the hardware-based write-ahead logging approach [10,22,27,35,37,68,72]. Figure 1 shows Capri architecture and illustrates the two-phase atomic store strategy with the decoupled proxy buffer architecture.…”

Section: Architecture-supported Regionmentioning

confidence: 99%

Capri

Jeong

Zeng

Jung

2022

Proceedings of the 31st International Symposium on High-Performance Parallel and Distributed Computing

View full text Add to dashboard Cite

This paper investigates whole-system persistence (WSP) that ensures hassle-free crash consistency for all programs while simultaneously leveraging both advantages of the non-volatile memory technologies: high-density and in-memory persistence. Despite the promising characteristics, there are two challenges that must be addressed to make WSP a reality. First, programs must be able to resume the execution from where they had a failure. Second, failure recovery must be offered to any program including the OS in a transparent manner while minimizing persistence overheads.To this end, this paper presents Capri, a compiler and architecture co-designed scheme for region-level whole-system persistence. First, the Capri compiler partitions program into a series of regions whose boundaries serve as recovery points. Then, the Capri architecture provides the regions with crash consistency through hardware-based atomic updates. Finally, with the novel interplay between the architecture and the compiler, Capri provides failure atomicity on the cheap, i.e., with 0%, 12.4%, and 9.1% performance overheads for SPEC CPU2017, STAMP, and Splash3 benchmarks, respectively. CCS CONCEPTS• Hardware → Emerging architectures; Emerging languages and compilers.

show abstract

“…The concept of persistence domain was initially linked to the feature of Asynchronous DRAM Refresh (ADR). ADR keeps DRAM in self-refresh mode and, more important, places pmem and the write pending queue (WPQ) of memory controller (MC) in the persistence domain [26,27,72], as it guarantees to flush data staying in the WPQ to pmem in case of a power outage. Later Intel extended ADR as eADR that further manages to flush all cache lines to pmem on a crash [2,3,13,24,30].…”

Section: Introductionmentioning

confidence: 99%

Enabling Atomic Durability for Persistent Memory with Transiently Persistent CPU Cache

Ye¹,

Chen²,

Jiang³

et al. 2022

Preprint

View full text Add to dashboard Cite

Persistent memory (pmem) products bring the persistence domain up to the memory level. Intel recently introduced the eADR feature that guarantees to flush data buffered in CPU cache to pmem on a power outage, thereby making the CPU cache a transient persistence domain. Researchers have explored how to enable the atomic durability for applications' in-pmem data. In this paper, we exploit the eADR-supported CPU cache to do so. A modified cache line, until written back to pmem, is a natural redo log copy of the in-pmem data. However, a write-back due to cache replacement or eADR on a crash overwrites the original copy. We accordingly develop Hercules, a hardware logging design for the transaction-level atomic durability, with supportive components installed in CPU cache, memory controller (MC), and pmem. When a transaction commits, Hercules commits on-chip its data staying in cache lines. For cache lines evicted before the commit, Hercules asks the MC to redirect and persist them into inpmem log entries and commits them off-chip upon committing the transaction. Hercules lazily conducts pmem writes only for cache replacements at runtime. On a crash, Hercules saves metadata and data for active transactions into pmem for recovery. Experiments show that, by using CPU cache for both buffering and logging, Hercules yields much higher throughput and incurs significantly fewer pmem writes than state-of-the-art designs.

show abstract

Distributed Logless Atomic Durability with Persistent Memory

Cited by 26 publications

References 34 publications

Asap

Asap

Capri

Enabling Atomic Durability for Persistent Memory with Transiently Persistent CPU Cache

Contact Info

Product

Resources

About