Lightweight Recoverable Virtual Memory

Summary

• Persistence
• Server Design
• RVM Primitives
  • How the Server Uses the Primitives
    • Transaction Optimizations
• Implementation
  • Crash Recovery
  • Log Truncation

Persistence

• Why?
  • Need of OS subsystems
• How?
  • Make virtual memory persistent
• Who will use it?
  • Subsystem designers if it is performant
    • In-memory cache
• How to make it efficient
  • Use persistent logs to record changes to virtual memory

Server Design

Persistent Metadta, normal datastructures + code go into Virtual Address Space

Create external data segments to back persistent data structures

• Designer’s choice to use single or multiple data structures

RVM Primitives

Initialization

• initialize(options)
• map(region, options)
• unmap(region)

Body of Server Code

• begin_xact(tid, restore_mode)
• set_range(tid, addr, size)
• end_xact(td, commit_mode)
• abort_xact(tid)

GC to reduce log space

• Provided by LRVM
  • User doesn’t not NEED to use these, but can for added flexibility
• flush()
• truncate()

Misc

• query_options(region)
• set_options(options)
• create_log(optins, len, mode)

Simplicity comes from having a small set of primitives

How the Server Uses the Primitives

Initialize address space from Ext Segs

begin_xact(tid, mode);
  set_range(tid, base_addr, num_of_bytes); // Creates an 'undo' record
  write_metadata(m1);                      // Contained in range
  write_metadata(m2);                      // Contained in range
end_xact(tid, mode);                       // Creates 'redo' record

You can set a no_restore mode to tell LRVM to not create undo record

No action created by LRVM for write_metadata

Flush redo log to disk (sync) before we consider changes to be committed

• Can be async based on mode

Transaction Optimizations

• no_restore mode in begin_xact
  • no need to initiate in-memory undo record
• no_flush mode in end_xact
  • no need to sync flush redo log to disk
    • lazy persistence
      • window of vulnerability

Implementation

Redo log

• All changes to different regions between begin_xact and end_xact
• “No undo-redo value logging”
  • undo log does not get synced to disk

Crash Recovery

To resume after crash:

1. Read redo log from disk
2. Apply to data segment

Log Truncation

1. Apply Crash Recovery protocol
2. Delete log

Done in parallel with forward processing

• By managing different epochs