An Analysis of Persistent Memory Use with WHISPER

Abstract

Emerging non-volatile memory (NVM) technologies promise durability with read and write latencies comparable to volatile memory (DRAM). We define Persistent Memory (PM) as NVM accessed with byte addressability at low latency via normal memory instructions. Persistent-memory applications ensure the consistency of persistent data by inserting ordering points between writes to PM allowing the construction of higher-level transaction mechanisms. An epoch is a set of writes to PM between ordering points. To put systems research in PM on a firmer footing, we developed and analyzed a PM benchmark suite called WHISPER (Wisconsin-HP Labs Suite for Persistence) that comprises ten PM applications we gathered to cover all current interfaces to PM. A quantitative analysis reveals several insights: (a) only 4% of writes in PM-aware applications are to PM and the rest are to volatile memory, (b) software transactions are often implemented with 5 to 50 ordering points (c) 75% of epochs update exactly one 64B cache line, (d) 80% of epochs from the same thread depend on previous epochs from the same thread, while few epochs depend on epochs from other threads. Based on our analysis, we propose the Hands-off Persistence System (HOPS) to track updates to PM in hardware. Current hardware design requires applications to force data to PM as each epoch ends. HOPS provides high-level ISA primitives for applications to express durability and ordering constraints separately and enforces them automatically, while achieving 24.3% better performance over current approaches to persistence.

Vorpal

“…The simulator models an out-of-order core running at 4GHZ. To test our solution, we use applications from the persistent memory Whisper suite for our evaluation [32].To model a non-volatile memory with slower write speed, we set the NVMM write latency to 600 cycles [11,32]). and set the NVMM read and DRAM read/write latency to 150 cycles.…”

Mod

“…While the contents of PM are preserved in case of a system failure, DRAM and other structures such as CPU registers and caches are wiped clean. This system model is similar to most prior work [5,30,33,46] and representative of Optane DCPMM.…”

“…The vector-swaps workload emulates the main computation in the canneal benchmark from the PARSEC suite [3]. The baseline map datastructure can be implemented by either hashmap or ctree from the WHISPER suite [33]. Here, we compare against hashmap which outperformed ctree on Optane DCPMM.…”

“…As we show in the rest of this section, the high flushing overheads in PM-STM are caused by excessive ordering constraints (sfence) limit the overlapping of long-latency flush instructions. Undo-logging techniques typically require 5-50 fences [33] per transaction. These fences mainly order log updates before the corresponding data updates.…”

Language-level persistency

“…Joshi et al [25] proposes efficient persist barriers that minimize the number of cache line write-backs on the critical path. HOPS [36], like DPO [30], extends the cache hierarchy to separately enforce the ordering constraints between persists from their respective durability constraints. Izraelevitz et al [24] provides an automatic transformation technique for non-blocking data structures to convert them to recoverable data structures under various persistency models.…”