The advent of persistent memory (PM) into our everyday computing environment is now imminent. New programming models and algorithms based on these models are being developed for such systems. However, current models require programs to be rewritten with persistence related primitives such as clflush and clwb or at least recompiled so that persistent mechanisms can be automatically inserted. This is a burden to program developers. Furthermore, executing legacy programs as-is can lead to application and system inconsistencies as unexpected faults occur. In this article, we propose µSnap, an operating system support that is based on checkpointing that allows legacy applications to be executed as-is without compromising consistency in systems that deploy PM. We implement a prototype of µSnap in the Linux kernel version 4.3.3, and measure and quantify the effect of µSnap for a wide range of applications. We find that µSnap incurs overhead for application execution compared to applications run without any notion of persistency, but that the overhead can be controlled to be minimal by appropriately setting the checkpointing interval. We argue that the benefit for paying this small cost can be tremendous in the sense that one can transparently guarantee the consistency of all legacy software written under the traditional programming model.

As DRAM reaches its density limitation, various new memory technologies such as STT-RAM and PCM are emerging as contenders for next generation memory. As these new types of memory, which we refer to as New Memory (NM), are byte addressable and nonvolatile, they are anticipated to, partially or wholly, take on the role of main memory and storage. The goal of this study is to evaluate how the read/write latency gap between the DRAM and NM and the asymmetric read and write latency of NM will affect the performance of applications. To this end, using an in-house ARM based embedded system that allows us to individually adjust the read and write latency. First, we use controlled, synthetic workloads to evaluate the latency effects. The main finding here, among others, is that write latency has little effect on performance due to various hardware mechanisms employed in current cache hardware. We then run the Stream, LMbench and PARSEC 3.0 benchmarks that represent real life applications with various memory latency settings. We find that write latency has virtually no effect and the effect of read latency is limited only to applications with very low cache hit rates.