Wednesday, September 16, 2009

Lightweight Recoverable Virtual Memory

Goal: How simple can a transactional facility be, while remaining a potent tool for fault-tolerance? The authors omitted what they could without crippling RVM.
RVM is intended for Unix applications with persistent data and the paper is presented in three parts: rationale, architecture, and implementation.

Rational: Existing solutions, such as Camelot, were too heavy-weight. The solution was a light version that provides only recoverable virtual memory. The central principle the authors adopted in designing RVM was to value simplicity over generality. The authors followed to systems principle of building simple components that do things well.

Architecture: LRVM is managed in segments as opposed to pages. Regions of the segments are mapped to Unix virtual memory. There is no aliasing: mappings cannot overlap in virtual memory and no region of a segment may be mapped more than once by the same process. Regions can be unmapped at any time, as long as they have no uncommitted transactions outstanding. The designers focused on using meta-data to minimize the disk space that recoverable memory would occupy. Many other small features were also omitted.

Implementation:
Log Management: No undo/redo since value logging strategy because it never reflects uncommitted changes to an external data segment. Crash recovery is idempotent by being done last. Log truncation is also handled.
Optimizations: Intra-transaction optimizations arise when set-range calls specifying identical, overlapping, or adjacent memory addresses are issued within a single transaction. Inter-transaction optimizations occur only in the context of no-flush transactions.

Result: RVM handles more transaction/sec than Camelot in all cases. However, the performance significantly drops when recoverable memory size approaches physical memory size.

Analysis: A lightweight RVM can provide the necessary functionally, while improving performance and modularity. This lesson can be applied in general when building a complex system. Additional features can be added later as components built on top of the system. While this paper did not demonstrate this idea, complex distributed systems today, such as Google, are built with layered component blocks providing a given functionality.

6 comments:

  1. I'm also visiting this site regularly, this web site is really nice and the users are genuinely sharing good thoughts. zerto

    ReplyDelete
  2. This is such an in fact cool blog; the piece of writing is truly precious for all of us.
    payday loans

    ReplyDelete
  3. Hmm this is one of my favorite blogs; it’s quite simple writing that can help me a lot. vehicle insurance

    ReplyDelete
  4. That’s really amazing and extraordinary blogs & can help those who get issues in searching this type of information.hacking tutorials

    ReplyDelete
  5. The complete blogs are really inconceivable and definitely everyone will share this information.term life insurance

    ReplyDelete
  6. I'm certainly very happy to read this blog site posts which carries plenty of helpful data, thanks for providing such information.
    iSpyyou

    ReplyDelete