Lightweight Recoverable Virtual Memory

1
Lightweight Recoverable Virtual Memory
2
Persistence

• Why?
• How?
• At what price?

3
Subsystems that can benefit from persistence

• File systems
• Runtime systems for PL that support persistence

4
Transaction

• Atomicity
• Consistency
• Isolation
• Durability
• Informally
• Atomicity, permanence, and serializability
• Solve a number of hairy system problems
• Why not simply use a database for everything?

5
Persistence via VM

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

Recoverable processes
Camelot system components
6
Distributed file systems and persistence

• Follow on to Suns NFS in several places
• Sprite at Berkeley
• AFS at CMU
• Coda at CMU (http//www.cs.cmu.edu/afs/cs/project/
  coda/Web/docdir/lj98.pdf)
• Disconnected operation for mobility
• Client side persistent caching
• Server replication
• Sharing
• Specifically Coda provides
• Optimistic replication protocol
• Atomicity and permanence
• Why not put Coda on top of Camelot
• Application in Figure is Coda
• Coda meta data in RVM of Camelot

7
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

8
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

9
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)

10
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

11

• 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
• Why these restrictions?
• Unmapping
• Can be done any time so long as no commits pending

12
RVM primitives
13
Implementation

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

14

• 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

15
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

16
Incremental Truncation
17
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

18
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?

19
Transactional Throughput
20
Scalability
21
Optimizations
22
Tidbits

• Spector (Camelot author) started Transarc
• Transarc bought by IBM
• Spector now is a VP at IBM
• Rick Rashid (Mach author) is now VP research at
  Microsoft