Enhancing Crash Consistency in Persistent Memory Systems

Explore how ThyNVM enables software-transparent crash consistency in persistent memory systems, overcoming challenges and offering a new hardware-based checkpointing mechanism that adapts to DRAM and NVM characteristics while reducing latency and overhead.

• Persistent memory
• ThyNVM
• Crash consistency
• Hardware-based checkpointing
• DRAM

kandacey Follow

Uploaded on Sep 10, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. ThyNVM Enabling Software-Transparent Crash Consistency In Persistent Memory Systems Jinglei Ren, Jishen Zhao, Samira Khan, Jongmoo Choi, Yongwei Wu, and Onur Mutlu

2. TWO-LEVEL STORAGE MODEL CPU Ld/St VOLATILE FAST BYTE ADDR MEMORY DRAM FILE I/O STORAGE NONVOLATILE SLOW BLOCK ADDR 2

3. TWO-LEVEL STORAGE MODEL CPU Ld/St VOLATILE FAST BYTE ADDR MEMORY DRAM FILE I/O NVM PCM, STT-RAM STORAGE NONVOLATILE SLOW BLOCK ADDR Non-volatile memories combine characteristics of memory and storage 3

4. PERSISTENT MEMORY CPU Ld/St PERSISTENT MEMORY NVM Provides an opportunity to manipulate persistent data directly 4

5. CHALLENGE: CRASH CONSISTENCY Persistent Memory System System crash can result in permanent data corruption in NVM 5

6. CURRENT SOLUTIONS Explicit interfaces to manage consistency NV-Heaps [ASPLOS 11], BPFS [SOSP 09], Mnemosyne [ASPLOS 11] AtomicBegin { Insert a new node; } AtomicEnd; Limits adoption of NVM Have to rewrite code with clear partition between volatile and non-volatile data Burden on the programmers 6

7. OUR APPROACH: ThyNVM Goal: Software transparent consistency in persistent memory systems 7

8. ThyNVM: Summary A new hardware-based checkpointing mechanism Checkpoints at multiple granularities to reduce both checkpointing latency and metadata overhead Overlapscheckpointing and execution to reduce checkpointing latency Adapts to DRAM and NVM characteristics Performs within 4.9% of an idealized DRAM with zero cost consistency 8

9. OUTLINE Crash Consistency Problem Current Solutions ThyNVM Evaluation Conclusion 9

10. CRASH CONSISTENCY PROBLEM Add a node to a linked list 2. Link to prev 1. Link to next System crash can result in inconsistent memory state 10

11. OUTLINE Crash Consistency Problem Current Solutions ThyNVM Evaluation Conclusion 11

12. CURRENT SOLUTIONS Explicit interfaces to manage consistency NV-Heaps [ASPLOS 11], BPFS [SOSP 09], Mnemosyne [ASPLOS 11] Example Code update a node in a persistent hash table void hashtable_update(hashtable_t* ht, void *key, void *data) { list_t* chain = get_chain(ht, key); pair_t* pair; pair_t updatePair; updatePair.first = key; pair = (pair_t*) list_find(chain, &updatePair); pair->second = data; } 12

13. CURRENT SOLUTIONS voidTMhashtable_update(TMARCGDECL hashtable_t* ht, void *key, void*data){ list_t* chain = get_chain(ht, key); pair_t* pair; pair_t updatePair; updatePair.first = key; pair = (pair_t*) TMLIST_FIND(chain, &updatePair); pair->second = data; } 13

14. CURRENT SOLUTIONS Manual declaration of persistent components void TMhashtable_update(TMARCGDECL hashtable_t* ht, void *key, void*data){ list_t* chain = get_chain(ht, key); pair_t* pair; pair_t updatePair; updatePair.first = key; pair = (pair_t*) TMLIST_FIND(chain, &updatePair); pair->second = data; } 14

15. CURRENT SOLUTIONS Manual declaration of persistent components void TMhashtable_update(TMARCGDECL hashtable_t* ht, void *key, void*data){ list_t* chain = get_chain(ht, key); pair_t* pair; pair_t updatePair; updatePair.first = key; pair = (pair_t*) TMLIST_FIND(chain, &updatePair); pair->second = data; } Need a new implementation 15

16. CURRENT SOLUTIONS Manual declaration of persistent components void TMhashtable_update(TMARCGDECL hashtable_t* ht, void *key, void*data){ list_t* chain = get_chain(ht, key); pair_t* pair; pair_t updatePair; updatePair.first = key; pair = (pair_t*) TMLIST_FIND(chain, &updatePair); pair->second = data; } can be inconsistent Need a new implementation Third party code 16

17. CURRENT SOLUTIONS Manual declaration of persistent components void TMhashtable_update(TMARCGDECL hashtable_t* ht, void *key, void*data){ list_t* chain = get_chain(ht, key); pair_t* pair; pair_t updatePair; updatePair.first = key; pair = (pair_t*) TMLIST_FIND(chain, &updatePair); pair->second = data; } can be inconsistent Operation Burden on the programmers Need a new implementation Prohibited Third party code 17

18. OUTLINE Crash Consistency Problem Current Solutions ThyNVM Evaluation Conclusion 18

19. OUR GOAL Software transparent consistency in persistent memory systems Executelegacy applications Reduce burden on programmers Enableeasier integration of NVM 19

20. NO MODIFICATION IN THE CODE void hashtable_update hashtable_update(hashtable_t* ht, void *key, void *data) { list_t* chain = get_chain(ht, key); pair_t* pair; pair_t updatePair; updatePair.first = key; pair = (pair_t*) list_find(chain, &updatePair); pair->second = data; }

21. RUN THE EXACT SAME CODE void hashtable_update(hashtable_t* ht, void *key, void *data){ list_t* chain = get_chain(ht, key); pair_t* pair; pair_t updatePair; updatePair.first = key; pair = (pair_t*) list_find(chain, pair->second = data; } &updatePair); Persistent Memory System Software transparent memory crash consistency 21

22. ThyNVM APPROACH Periodic checkpointing of data managed by hardware time Running Running Checkpointing Checkpointing Epoch 0 Epoch 1 Transparent to application and system 22

23. CHECKPOINTING OVERHEAD 1. Metadata overhead Metadata Table Checkpoint location Working location X X Y Y time Running Running Checkpointing Checkpointing Epoch 0 Epoch 1 2. Checkpointing latency 23

24. 1. METADATA AND CHECKPOINTING GRANULARITY Checkpoint location Working location X X Y Y CACHE BLOCK PAGE PAGE BLOCK GRANULARITY GRANULARITY One Entry Per Page Small Metadata One Entry Per Block Huge Metadata 24

25. 2. LATENCY AND LOCATION DRAM-BASED WRITEBACK 2. Update the metadata table Checkpoint location from DRAM Working location 1. Writeback data X X W NVM DRAM Long latency of writing back data to NVM 25

26. 2. LATENCY AND LOCATION NVM-BASED REMAPPING 2. Update the metadata table 1. No copying 3. Write in a Checkpoint location X of data new location Working location Y NVM DRAM Short latency in NVM-based remapping 26

27. ThyNVM KEY MECHANISMS Checkpointing granularity Small granularity: large metadata Large granularity: small metadata Latency and location Writeback from DRAM: long latency Remap in NVM: short latency Based on these we propose two key mechanisms 1. Dual granularity checkpointing 2. Overlap of execution and checkpointing

28. 1. DUAL GRANULARITY CHECKPOINTING Page Writeback in DRAM Block Remapping in NVM NVM DRAM GOOD FOR STREAMING WRITES GOOD FOR RANDOM WRITES High write locality pages in DRAM, low write locality pages in NVM 28

29. 2. OVERLAPPING CHECKOINTING AND EXECUTION time Running Running Checkpointing Checkpointing Epoch 1 Epoch 0 time Epoch 0 Epoch 1 Running Checkpointing Running Checkpointing Running Checkpointing Epoch 0 Epoch 1 Epoch 2 Hides the long latency of Page Writeback

30. OUTLINE Crash Consistency Problem Current Solutions ThyNVM Evaluation Conclusion 30

31. METHODOLOGY Cycle accurate x86 simulator Gem5 Comparison Points: Ideal DRAM: DRAM-based, no cost for consistency Lowest latency system Ideal NVM: NVM-based, no cost for consistency NVM has higher latency than DRAM Journaling: Hybrid, commit dirty cache blocks Leverages DRAM to buffer dirty blocks Shadow Paging: Hybrid, copy-on-write pages Leverages DRAM to buffer dirty pages 31

32. ADAPTIVITY TO ACCESS PATTERN RANDOM SEQUENTIAL 3 3 Normalized Write Normalized Write B E T T E R Traffic To NVM Traffic To NVM 2 2 1 1 0 0 Journal ShadowThyNVM Journaling is better for Random and Shadow paging is better for Sequential Journal ShadowThyNVM ThyNVM adapts to both access patterns 32

33. OVERLAPPING CHECKPOINTING AND EXECUTION RANDOM SEQUENTIAL 60 Execution Time 60 B E T T E R Execution Time Percentage of Percentage of 40 40 20 20 0 0 Journal ShadowThyNVM Journal ShadowThyNVM ThyNVM spends only 2.4%/5.5% of the execution time on checkpointing on checkpointing Can spend 35-45% of the execution Stalls the application for a negligible time 33

34. PERFORMANCE OF LEGACY CODE Ideal DRAM Ideal NVM ThyNVM 1 Normalized IPC 0.8 0.6 0.4 0.2 0 gcc bwaves milc leslie. soplex Gems lbm omnet Within -4.9%/+2.7% of an idealized DRAM/NVM system Provides consistency without significant performance overhead 34

35. OUTLINE Crash Consistency Problem Current Solutions ThyNVM Evaluation Conclusion 35

36. ThyNVM A new hardware-based checkpointing mechanism, with no programming effort Checkpoints at multiple granularities to minimize both latency and metadata Overlapscheckpointing and execution Adapts to DRAM and NVM characteristics Can enable widespread adoption of persistent memory 36

37. Available at http://persper.com/thynvm ThyNVM Enabling Software-transparent Crash Consistency In Persistent Memory Systems Jinglei Ren, Jishen Zhao, Samira Khan, Jongmoo Choi, Yongwei Wu, and Onur Mutlu