iDO: Compiler-Directed Failure Atomicity for Nonvolatile Memory

Liu, Qingrui; Izraelevitz, Joseph; Lee, Se Kwon; Scott, Michael L.; Noh, Sam H.; Jung, Chong‐Hun

doi:10.1109/micro.2018.00029

Cited by 81 publications

(41 citation statements)

References 45 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…To facilitate more general use of persistence, several groups have developed libraries and, in some cases, compiler-based systems to provide failure atomicity for programmer-delimited blocks of code. In some systems, these blocks are outermost lock-based critical sections, otherwise known as failure-atomic sections (FASEs); examples in this camp include Atlas [6], JUSTDO [24], and iDO [31]. In other systems, the atomic blocks are transactions, which may be speculatively executed in parallel with one another; examples in this camp include Mnemosyne [50], NV-Heaps [10], QSTM [1], and OneFile [39].…”

Section: Runtime and Applicationsmentioning

confidence: 99%

“…Ensuring such consistency generally requires that code be instrumented with explicit write-back and fence instructions, to avoid the possibility that updated values may still reside only in the (transient) cache when data that depend upon them have already been written back. To save the programmer the burden of hand instrumentation, various groups have developed persistent versions of popular data structures [18,37,54,55] as well as more general techniques to add failure atomicity [6] to code based on locks [6,24,31], transactions [1,10,14,39,50], or both [41].…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Understanding and optimizing persistent memory allocation

Cai

Wen

Beadle

et al. 2020

Proceedings of the 25th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming

Self Cite

View full text Add to dashboard Cite

The proliferation of fast, dense, byte-addressable nonvolatile memory suggests that data might be kept in pointer-rich "in-memory" format across program runs and even process and system crashes. For full generality, such data requires dynamic memory allocation, and while the allocator could in principle be "rolled into" each data structure, it is desirable to make it a separate abstraction.Toward this end, we introduce recoverability, a correctness criterion for persistent allocators, together with a nonblocking allocator, Ralloc, that satisfies this criterion. Ralloc is based on the LRMalloc of Leite and Rocha, with three key innovations. First, we persist just enough information during normal operation to permit correct reconstruction of the heap after a fullsystem crash. Our reconstruction mechanism performs garbage collection (GC) to identify and remedy any failure-induced memory leaks. Second, we introduce the notion of filter functions, which identify the locations of pointers within persistent blocks to mitigate the limitations of conservative GC. Third, to allow persistent regions to be mapped at an arbitrary address, we employ position-independent (offset-based) pointers for both data and metadata.Experiments show Ralloc to be performance-competitive with both Makalu, the state-of-theart lock-based persistent allocator, and such transient allocators as LRMalloc and JEMalloc. In particular, reliance on GC and offline metadata reconstruction allows Ralloc to pay almost nothing for persistence during normal operation.

show abstract

Section: Runtime and Applicationsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Understanding and optimizing persistent memory allocation

Cai

Wen

Beadle

et al. 2020

Proceedings of the 25th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming

Self Cite

View full text Add to dashboard Cite

show abstract

“…Previous work like Atlas [7], JUSTDO [37], NVThreads [31], and iDO [50], persist data at boundaries of critical sections called Failure Atomic SEctions (FASE). They automatically inject logging for every persistent update [7,31] or program states [37,50] within FASE by using compile-time analysis. However, their approaches amplify the overhead of cache line flushes, as they require an additional persistent log.…”

Section: Related Workmentioning

confidence: 99%

Recipe

Lee

Mohan

Kashyap

et al. 2019

Proceedings of the 27th ACM Symposium on Operating Systems Principles

Self Cite

120

View full text Add to dashboard Cite

We present Recipe, a principled approach for converting concurrent DRAM indexes into crash-consistent indexes for persistent memory (PM). The main insight behind Recipe is that isolation provided by a certain class of concurrent in-memory indexes can be translated with small changes to crash-consistency when the same index is used in PM. We present a set of conditions that enable the identification of this class of DRAM indexes, and the actions to be taken to convert each index to be persistent. Based on these conditions and conversion actions, we modify five different DRAM indexes based on B+ trees, tries, radix trees, and hash tables to their crash-consistent PM counterparts. The effort involved in this conversion is minimal, requiring 30-200 lines of code. We evaluated the converted PM indexes on Intel DC Persistent Memory, and found that they outperform state-of-the-art, hand-crafted PM indexes in multi-threaded workloads by up-to 5.2×. For example, we built P-CLHT, our PM implementation of the CLHT hash table by modifying only 30 LOC. When running YCSB workloads, P-CLHT performs up to 2.4× better than Cacheline-Conscious Extendible Hashing (CCEH), the state-of-the-art PM hash table.

show abstract

“…At this point, we would have a durable log of the data we are about to modify. Then, we begin the transaction execution (lines [22][23][24][25][26][27][28][29][30][31][32][33][34][35][36][37][38][39][40]. After finishing the transaction, we reset the insideTx bit and make it durable, indicating that the transaction has completed (lines 43-45).…”

Section: Durable Transactions With Write Ahead Loggingmentioning

confidence: 99%

Efficient Checkpointing with Recompute Scheme for Non-volatile Main Memory

Alshboul

Elnawawy

Elkhouly

et al. 2019

ACM Trans. Archit. Code Optim.

View full text Add to dashboard Cite

Future main memory will likely include Non-Volatile Memory. Non-Volatile Main Memory (NVMM) provides an opportunity to rethink checkpointing strategies for providing failure safety to applications. While there are many checkpointing and logging schemes in the literature, their use must be revisited as they incur high execution time overheads as well as a large number of additional writes to NVMM, which may significantly impact write endurance.In this article, we propose a novel recompute-based failure safety approach and demonstrate its applicability to loop-based code. Rather than keeping a fully consistent logging state, we only log enough state to enable recomputation. Upon a failure, our approach recovers to a consistent state by determining which parts of the computation were not completed and recomputing them. Effectively, our approach removes the need to keep checkpoints or logs, thus reducing execution time overheads and improving NVMM write endurance at the expense of more complex recovery. We compare our new approach against logging and checkpointing on five scientific workloads, including tiled matrix multiplication, on a computer system model that was built on gem5 and supports Intel PMEM instruction extensions. For tiled matrix multiplication, our recompute approach incurs an execution time overhead of only 5%, in contrast to 8% overhead with logging and 207% overhead with checkpointing. Furthermore, recompute only adds 7% additional NVMM writes, compared to 111% with logging and 330% with checkpointing. We also conduct experiments on real hardware, allowing us to run our workloads to completion while varying the number of threads used for computation. These experiments substantiate our simulation-based observations and provide a sensitivity study and performance comparison between the Recompute Scheme and Naive Checkpointing. INTRODUCTIONNon-volatile memory (NVM) technologies have been advancing rapidly, and some of them are a strong contender for use as a future main memory, either for augmenting or replacing DRAM. One such an example is 3D Xpoint memory, which will be brought to market in 2017 by Intel and Micron [28]. These new non-volatile main memory (NVMM) technologies are byte-addressable and have access latencies that are not much slower than DRAM [3,6,8,28,34,37,38,50]. NVMMs are expected to have a limited write endurance, making it imperative to keep the number of writes low [7]. Despite the limited write endurance and relatively high write latency compared to DRAM, NVMM's density and cost advantage over DRAM and near-zero idle power consumption make them a compelling candidate to replace or augment DRAM in high-performance computers [5].At the same time, as high-performance computing (HPC) relies on an increasing number of nodes and components, it becomes increasingly likely that long-running computation will be interrupted by failures before completing. Frequent checkpointing has become essential because it allows applications to resume from a recent snapshot rather than re-execute from ...

show abstract

iDO: Compiler-Directed Failure Atomicity for Nonvolatile Memory

Cited by 81 publications

References 45 publications

Understanding and optimizing persistent memory allocation

Understanding and optimizing persistent memory allocation

Recipe

Efficient Checkpointing with Recompute Scheme for Non-volatile Main Memory

Contact Info

Product

Resources

About