MachineIndependent Virtual Memory Management for Paged Uniprocessor and

Machine-Independent Virtual Memory Management for Paged Uniprocessor and Multiprocessor Architectures Jordan Acedera Ishmael Davis Justin Augspurger Karl Banks

Introduction • Many OS do not have VM support • Mach goals: – Exploit hardware/software relationship – Portability – Handling of page faults • Mach extends UNIX support • Compatibility

Compatibility • Mach runs on the following systems: – VAX processors – IBM RT PC – SUN 3 – Encore Multimax – Sequent Balance 21000

Mach Design • Basic abstractions – Task – Thread – Port – Message – Memory Object

Mach Design • Basic Operations – Allocate memory – Deallocate memory – Set protection status – Specify inheritance – Create/Manage memory objects • Limits of Mach Design

Mach Design

The Implementation of Mach Virtual Memory Presented by: Karl Banks

Data Structures • Resident page table: keeps track of Mach pages residing in main memory (machine independent) • Address map: a doubly linked list of map entries, each of which maps a range of virtual addresses to a region of a memory object • Memory object: a unit of backing storage such as a disk file or a swap area • Pmap: the memory-mapping data structure used by the hardware (machine dependent)

Pager • Managing task; one associated with each memory object • Handles page faults and page-out requests outside of the kernel • If kernel sends pageout request to a user-level pager, it can decide which page to swap out • If pager is uncooperative, default pager will be invoked to perform the necessary pageout

Mach Implementation Diagram Virtual address space of a process Default Pager Swap area External Pager File System

Sharing Memory: Copy-on-Write • Case: tasks only read • Supports memory-sharing across tasks

Sharing Memory: Copy-on-Write • Case: write “copied” data • New page allocated only to writing task • Shadow object created to hold modified pages

Sharing Memory: Shadow Objects • Collects modified pages resulting from copy-onwrite page faults • Initially empty with pointer to its shadowed object • Only contains modified pages, relies on original object for rest • Can create chain of shadow objects • System proceeds through list until page is found • Complexity handled by garbage collection

Sharing Memory: Read/Write • Data structure for copy-on-write not appropriate (read/write sharing could involve mapping several memory objects) • Level of indirection needed for a shared object

Sharing Memory: Sharing Maps • Identical to address map, points to shared object • Address maps point to sharing maps in addition to memory objects • Map operations are then applied simply to sharing map • Sharing maps can be split and merged, thus no need to reference others

Virtual Memory Management Part 2 Jordan Acedera Karl Banks Ishmael Davis Justin Augspurger

Porting Mach • • First installed on VAX architecture machines By May 1986 it was available for use – • IBM RT PC, SUN 3, Sequent Balance, and Encore Multi. MAX machines. A year later there were 75 IBM RT PC’s running Mach

Porting Mach • • • All 4 machine types took about the same time to complete the porting process Most time spent was debugging the compilers and device drivers Estimated time was about 3 weeks for the pmap module implementation – Large part of that time was spent understanding the code

Assessing Various Memory Management Architectures • • Mach does not need the hardware data structure to manage virtual memory Mach – • Need malleable TLB, with little code needed written for the pmap Pmap module will manipulate the hardware defined in-memory structures, which will control the state of the internal MMU TLB. – Though this is true, each hardware architecture has had issues with both the uni and multi processors.

Uniprocessor Issues • Mach on the VAX – • Problem – • In theory a 2 Gb address space is allocated to a process not practical - A large amount of space needed linear page table (8 MB) UNIX – – Page tables in physical memory Addresses only get 8, 16, or 64 MB per process

Uniprocessor Issues • VAX VMS – • Pageable tables in the kernel’s virtual address space. Mach on the VAX – – Page tables kept in physical memory Only constructs the parts needed to map the virtual to real address for the pages currently being used.

Uniprocessor Issues • IBM RT PC – Uses a single inverted page (not per-task table) • – • Describes mapping for the addresses Uses the hashing function for the virtual address translation (allows a full 4 GB address space) Mach on IBM RT PC – – – Reduced memory requirements benefits Simplified page table requirements Only allows one mapping for each physical page (can cause page faults when sharing)

Uniprocessor Issues • SUN 3 – – Segments and page tables are used for the address maps (up to 256 MB each) Helps with implementing spares addressing • • Only 8 contexts can exist at one time Mach on the SUN 3 – SUN 3 had an issue with display memory addressable as “high” physical memory. • The Mach OS handled the issue with machine dependent code

Uniprocessor Issues • Encore Multimax and Sequent Balance – Both Machines used the National 32082 MMU, which had problems • • • Only 16 MB of VM can be addressed per page table Only 32 MB of physical memory can be addressed. A read-modify-write fault reported as a read fault – – Mach depended on correct faults being handled This was taken care of with the next MMU – National 32382

Multiprocessor Issues • • • None of the multiprocessors running Mach supported TLB consistency To guarantee consistency, the kernel will have to know which processors have the old mapping in the TLB and make it flush Unfortunately – its impossible to reference or modify a TLB remotely or any of the multi processors running Mach

Multiprocessor Issues • 3 solutions – 1 interrupt all CPU’s using a shared portion of an address and flush their buffers • – 2 hold on map changing until all CPU’s have been flushed using a timer interrupt • – When a change is critical When mappings need to be removed from the hardware address maps 3 allow temp inconsistency • Acceptable because the operation semantics do not need to be simultaneous

Integrating Loosely-coupled and Tightlycoupled Systems • Difficulties in building a universal VM model – – different address translation hardware different shared memory access between multiple CPUs • fully shared/uniform access time (Encore Multi. Max, Sequent Balance) • shared/non-uniform access time (BBN Butterfly, IBM RP 3) • non-shared, message-based (Intel Hypercube) • Mach is ported only for uniform shared memory (tightlycoupled) multiprocessor systems • Mach does contain mechanisms for loosely-coupled multiprocessor systems.

Measuring VM Performance • Mach performance is favored

Measuring VM Performance • • Program compiling, Compiling Mach kernel Mach performance is favored

Relations to Previous Work • Mach's VM functionality derives from earlier OS – Accent and/or Multics • Virtual space segment creation corresponding with files and other permanent data • Efficient, large VM transfers between protected address spaces – Apollo's Aegis, IBM's System/38, CMU's Hydra • Memory mapped objects – Sequent's Dynix, Encore's Umax • Shared VM systems for multiprocessors

Relations to Previous Work • Mach differs in its sophisticated VM features not tied to a specific hardware base • Mach differs in its ability to additionally work in a distributed environment

Conclusion • Growth of portable software and use of more sophisticated VM mechanisms lead to a need for a less intimate relationship between memory architecture and software • Mach shows possibilities of – Portable VM management with few reliances on system hardware – VM management without negative performance impact • Mach runs on a variety of machine architectures