VAX/VMS Virtual Memory review

From: David Coleman (dcoleman_at_cs.washington.edu)
Date: Wed Feb 11 2004 - 14:31:59 PST

  • Next message: Richard Jackson: "Review: H. Levy and P. Lipman. Virtual Memory Management in VAX/VMS."

    The first portion of “Virtual Memory Management in the VAX/VMS Operating
    System” describes the hardware platform VMS was designed to run on and
    then gives a brief description of address space layout followed by a
    discussion of the virtual memory management system.

    VMS breaks process space up into two partitions (called P0 and P1) and
    allocates the upper half of the address space for the system (although
    only half of that area is defined and used). Each of these three
    partitions have their own page tables which is an interesting approach.
    Also unique is that the process-specific page tables (for areas P0 and
    P1) are themselves pageable. The use of a 512 byte page increases the
    page table size and thus pageable page tables are probably necessary.

    The concept of paging on a process-local basis instead of a global basis
    seems like an efficient approach. I would have liked to have seen a
    justification of using a FIFO algorithm instead of a UNIX-style clock
    algorithm. Free and modified lists appear to be global (which makes
    sense) and provide nice performance improvements both by allowing
    clustering of writes and providing a basic level of caching in case of
    poorly chosen page replacements. Does the OS ever do resident set
    trimming under a heavy process load?

    One observation about the paper. It states that clustering is also used
    in the paging file, but there is less chance of finding virtually
    contiguous pages that are physically contiguous on disk due to the
    paging file supporting multiple processes. It then goes on to state that
    when writing the modified list when it hits its upper limit, it writes
    high limit – low limit number of pages to a physically contiguous area
    of the paging file for speed. I’m probably not understanding something,
    but these two statements seem to conflict.

    I wasn’t exactly clear on when the swapper would swap out an entire
    process. Was it only when it blocked or simply when there were more
    higher priority processes available to run?

    I really liked the fine-grained memory control available to the
    application. As we’ve seen all quarter, it is impossible for a general
    purpose system to get the maximum performance in all cases and this
    allows seemingly significant tuning to improve application performance.

    It was interesting to compare this approach with how Windows 2000 does
    it. It seems that this approach had a large effect on the field and
    continues to influence implementations today.


  • Next message: Richard Jackson: "Review: H. Levy and P. Lipman. Virtual Memory Management in VAX/VMS."

    This archive was generated by hypermail 2.1.6 : Wed Feb 11 2004 - 14:29:31 PST