Lightweight Recoverable Virtual Memory

1
Lightweight Recoverable Virtual Memory

• Edited from Last Falls Lecture

2
Concept

• An abstract (RVM), a library
• Atomicity, permanence, and serializability

Target App

• Persistent Data (Small size meta-data etc)

3
Subsystems that can benefit from persistence

• File systems
• Runtime systems for PL that support persistence

4
Transaction

• Atomicity
• Consistency
• Isolation
• Durability

5
Persistence via VM

• Camelot (CMU) pioneered this approach
• Built on top of MACH

Recoverable processes
Camelot system components
6
Pros and Cons

• Pros
• RVM a powerful abstraction for systems
• Cons
• Camelot an overkill
• Poor scalability extensive paging (interaction
  between the components shown in Figure 1) leading
  to increased CPU load on the servers
  
• Programming constraints structure of apps under
  Camelot Mach threads mandatory
  
• Code size Camelot structure on top of Mach

7
New Design of RVM

• Rationale
• Keep it simple
• Pull out stuff that may not be needed by all
  subsystems
  
• No nesting
• No concurrency control
• No dependence on kernel threads
• No resiliency
• Portability
• Use only small, widely supported Unix subset of
  system interface
  

8
LRVM

• Assumptions
• Disk space not an issue
• RVM meant to support meta data for services such
  as a FS
  
• Differences from Camelot
• VM and recoverable regions decoupled
• RVM cannot be shared across processes
• Implemented as a library (as opposed to server
  processes) linked in with the application
  
• Implications
• Need to trust applications
• Cannot share write-ahead log for all
  applications
  
• Each process using RVM has its own log (either a
  file or a separate raw disk partition)

9
Architecture

• Segments and regions (logical)
• 264 bytes long in the design modulo actual
  hardware limits
  
• External data segment backs each segment
• VM maps these segments

10

• Mapping
• Apps explicitly map regions of segments into VM
• Data copied from external data segments into VM
  upon mapping (difference from Camelot)
  
• One to one mapping between VM and region
• No overlap of regions page-aligned
• Unmapping
• Can be done any time so long as no commits pending

11
RVM primitives
12
Implementation

• No undo/redo value logging strategy
• Only new value records of committed transactions
  written to log

13

• Upon commit
• Old value records replaced by new value records
  in VM
  
• Force new value records to log
• Write commit record
• No-restore no-flush transactions
• No need to copy old value records (no restore
  implies transaction will not abort)
  
• New value and commit records can be spooled than
  forced to log (lazy commitment)
  
• Bounded persistence period of log flushes

14
Crash recovery

• Read the log
• Apply to the external data segment
• Log emptied
• Truncating the log
• Epoch truncation
• Apply crash recovery algorithm to part of the log
  while allowing forward processing

15
Incremental Truncation
16
Optimization

• Intra-transaction
• Eliminate duplicate set-range calls
• Inter-transaction
• (only no flush transactions)
• e.g. cp dir1/ dir2
• Force only the last update of dir2 meta-data

17
Evaluation

• Software engineering perspective
• Code size comparison of RVM and Camelot
• 10K vs 60K
• System performance
• Lack of RVM and VM integration hurt?
• What do you expect?
• Scalability?
• What do you expect
• Do Optimizations help?
• What do you expect?

18
Transactional Throughput
19
Scalability
20
Optimizations