Lightweight Recoverable Virtual Memory

1. Lightweight Recoverable Virtual Memory Edited from Last Fall’s 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) • 2**64 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