NICO: Reducing Software-Transparent Crash Consistency Cost for Persistent Memory

Wei, Xueliang; Feng, Dan; Tong, Wei; Liu, Jingning; Ye, Liuqing

doi:10.1109/tc.2018.2876829

Cited by 6 publications

(6 citation statements)

References 28 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Despite being hardware, most of them 2,3,9,14‐16,21,23,25‐27,29 are non‐software‐transparent, depending on programming models PTM‐based to indicate atomic transactions, being hardware restricted to handle logs and checkpoint metadata. In contrast, other works 1,3,10,19,22 proposed software‐transparent approaches. ThyNVM 10 adopts a synchronized overlapping epochs model, but the need for synchronization affects system performance, especially in multi‐core systems.…”

Section: Related Workmentioning

confidence: 98%

“…However, to reduce space overhead, both pages need a process defined as recycling, making it cost‐effective. NICO 22 designed a lightweight checkpointing scheme that needs to flush and modify a smaller amount of data when creating a consistent snapshot of persistent memory data. However, like PiCL, it also increases traffic between processor and memory.…”

Section: Related Workmentioning

confidence: 99%

“…A second way to categorize these mechanisms is by the crash consistency technique adopted. The most common is by logging, which subdivides into redo-logging, 2,8,10,11,14,15,[20][21][22][23][24] undo-logging, 9,16,18,19,25 or a hybrid proposal of both. 26,27 Furthermore, other works have implemented shadow-paging, 1,28,29 logging-structured 30 and out-of-placing 3 techniques.…”

Section: Related Workmentioning

confidence: 99%

“…Exceptions to this hardware flush procedure are ATOM, 9 Proteus, 25 and SSP, 29 which persist via software flush using hardware to manage logs earlier in order to keep them outside the critical execution path. Hardware-based approaches use several persistence techniques, such as shadow-paging 1,29,41 and out-of-place updates proposed by HOOP, 3 but the most common is write-ahead logging (WaL), varying from undo-logging, 9,16,19,25 redo-logging, 2,10,14,15,[21][22][23] or a hybrid approach of undo + redo logging. 26,27 These works use logging hardware to generate log entries and coordinate data write-backs in the background, overlapping persistence with execution.…”

Section: Hardware-basedmentioning

confidence: 99%

“…¶¶ Other similar works are: ThyNVM, 10 NICO 22 and dual‐page checkpointing 1 . We discarded non‐software‐transparent mechanisms.…”

mentioning

confidence: 99%

See 4 more Smart Citations

DONUTS: An efficient method for checkpointing in non‐volatile memories

Kruger

Pannain

Azevedo

2023

Concurrency and Computation

View full text Add to dashboard Cite

Non-volatile memory (NVM) is an emerging technology being explored as an alternative to DRAM main memory in computing systems because of its persistence, higher storage density, lower energy consumption, and access latency close to DRAM. However, persistent memory systems must ensure data consistency on system failures, a property known as crash consistency. One of the main challenges in these systems is creating efficient checkpointing mechanisms in terms of performance and usability. Thus, it is necessary to remove persistence from the critical execution path and reduce the excessive number of writes to NVM caused by logging operations, resulting in increased memory bandwidth usage. Another limitation is that most proposed mechanisms restrict application source code to programming interfaces based on transactional models, typed as software-based approaches. These factors make it challenging to adopt NVM systems. This article presents a software-transparent mechanism based on dynamic epochs with logging operations via processing-in-memory and checkpoints integrated into the cache replacement policy. Compared to the previous best-performing system, our strategy reduces 50.6% of writes to NVM. Furthermore, it does not increase the average memory bandwidth usage, providing crash consistency with less than 2% runtime overhead.

show abstract

Section: Related Workmentioning

confidence: 98%

Section: Related Workmentioning

confidence: 99%