MACHINE-INDEPENDENT VIRTUAL MEMORY MANAGEMENT FOR PAGED UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURE...
Download
1 / 27

R. Rashid, A. Tevanian, M. Young, D. Golub, R. Baron, D. Black, W. Bolosky and J. Chew - PowerPoint PPT Presentation


  • 59 Views
  • Uploaded on

MACHINE-INDEPENDENT VIRTUAL MEMORY MANAGEMENT FOR PAGED UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES. R. Rashid, A. Tevanian, M. Young, D. Golub, R. Baron, D. Black, W. Bolosky and J. Chew Carnegie-Mellon University IEEE Trans. on Computers ,1988. THE PAPER.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'R. Rashid, A. Tevanian, M. Young, D. Golub, R. Baron, D. Black, W. Bolosky and J. Chew' - devaki


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

MACHINE-INDEPENDENT VIRTUAL MEMORY MANAGEMENT FOR PAGED UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

R. Rashid, A. Tevanian, M. Young, D. Golub, R. Baron, D. Black, W. Bolosky and J. Chew

Carnegie-Mellon University

IEEE Trans. on Computers,1988


The paper
THE PAPER UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Presents the Mach virtual memory system

  • Three most important issues:

    • Use of external pagers to support mapped files

    • Concept of inheritance

    • Copy on write

  • Shortened version of A. Tevanian’s dissertation


General objectives
GENERAL OBJECTIVES UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • To be as portable as the UNIX virtual memory system while supporting more functionality:

    • Mapped files

    • Threads through page inheritance

  • To support multiprocessing, distributed systems and large address spaces


Virtual memory and i o buffering i
Virtual Memory and I/O Buffering (I) UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Current situation:

Process in main memory

System calls

Virtual

Memory

I/O buffer

Swap

area

Disk

Drive


Virtual memory and i o buffering ii
Virtual Memory and I/O Buffering (II) UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • In a VM system, we have

    • Implicit transfers of data between main memory and swap area (page faults, etc.)

    • Implicit transfers of information between the disk drive and the system I/O buffer

    • Explicit transfers of information between the I/O buffer and the process address space


Virtual memory and i o buffering iii
Virtual Memory and I/O Buffering (III) UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • I/O buffering greatly reduces number of disk accesses

  • Each I/O request must still be serviced by the OS:

    • Two context switches per I/O request

  • A better solution consists of mapping files in the process virtual address space


Mapped files i
Mapped files (I) UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

Process in main memory

Usual VM

Pager

“External”

Pager

Swap

area

Disk

Drive


Mapped files ii
Mapped files (II) UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • When a process opens a file, the whole file is mapped into the process virtual address space

    • No data transfer takes place

  • File blocks are brought in memoryon demand

  • File contents are accessed using regular program instructions (or library functions)

  • Shared files are in shared memory segments


Mach implementation
Mach implementation UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

Process virtual address space

Usual VM

Pager

“External”

Pager

Swap

area

FileSystem


Comments
Comments UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Solution requires very large address spaces

  • Most programs will continue to access files through calls to read() and write()

    • Function calls instead of system calls

  • Two major problems

    • Harder to know the exact size of a file

    • Much harder to emulate the UNIX consistency model in a distributed file system

      • How can we have atomic writes?


Threads
Threads UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Also known as lightweight processes

  • Share the address space of their parent

  • Can be

    • Kernel-supported

    • Implemented at user level

  • Kernel-supported threads are essential in multiprocessor architectures


Mach vm user interface
Mach VM user interface UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Consistent on all machines supporting Mach: including the features that cannot be efficiently implemented on a specific hardware

  • Full support for multiprocessing: thread support, efficient data sharing mechanisms, etc..

  • Modular paging: external pagers are allowed to implement file mapping or recoverable virtual memory (for transaction management).


Vm implementation
VM IMPLEMENTATION UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Main implementation problem was hardware incompatibilities

  • BSD VM implementation was tailored to VAX hardware (and its lack of a page-referenced bit)

  • Mach designers wanted a design that would be architecture neutral

    • Many competing microprocessor architectures were then available


Data structures
Data structures UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Resident page table: keeps track of Mach pages residing in main memory

  • Memory object: a unit of backing storage such as a disk file or a swap area

  • 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

  • P-map: the memory-mapping data structure used by the hardware


The address map

First UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

Current

Last

VM

VM

From

From

To

To

Object

Object

Offset

Offset

Protection

Protection

Inheritance

Inheritance

Previous

Previous

Next

Next

The address map

First

could map code segment

(inheritance = share)

could map stack segment

(inheritance = copy)


Inheritance i
Inheritance (I) UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • After a regular UNIX fork()

    • code segment is shared between parent and child

    • child inherits a copy of data segment of parent

  • Mach inheritance attribute specifies if pages in a given range of addresses are to be shared, copied or ignored


Inheritance ii
Inheritance (II) UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Pages of a mapped file are always shared between parent and child to preserve file sharing semantics

  • Pages in the data segment can either be

    • copied to maintain UNIX fork() semantics

    • shared if we want to create a thread instead of a regular UNIX process


Lazy evaluation
Lazy evaluation UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Mach VM system postpones execution of tasks whenever possible

  • Approach is based on the belief that task is likely to become unnecessary

    • copying whole data segment of parent process in a fork() that is very likely to be followed by an exec()

    • Mach uses copy-on-write


Copy on write i
Copy on write (I) UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Already present in Accent

  • Best solution for efficient implementation of UNIX fork()

  • When Mach is told to copy a range of pages, it lets processes share the same copy of each page but traps write accesses

  • Only pages that are modified are copied


Copy on write ii
Copy on write (II) UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

Process A and B share a range of pages

X

COW creates new copy

Process B tries to modify shared page


Page replacement policy i
Page replacement policy (I) UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

Global pool of pages

FIFO

Expelled pages

Reclaimed pages

Global Queue

Disk


Page replacement policy ii
Page replacement policy (II) UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Similar to that of VAX VMS

    • Requires little hardware support

  • Major change is global FIFO pool replacing resident sets of all programs

    • Much easier to tune

    • Does not support real-time processes

    • Can use external pagers


Locks and deadlocks
Locks and deadlocks UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Mach VM algorithms rely on locks to achieve exclusive access to kernel data structures

    • Price to pay for a parallel kernel

  • To prevent deadlocks, all algorithms gain locks using the same linear ordering

    • Well known deadlock prevention technique


Miscellanea
Miscellanea UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Total size of the machine-dependent part of Mach VM implementation is about 16 Kbytes.

  • Copy-on-write is used to implement efficient message passing :

    • Messages are shared by sender and receiver until either of them modifies the data.

  • Shared librariesare supported through the mapped file interface


Problem with inverted page table
Problem with inverted page table UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • IBM RT had a single inverted page table for its whole memory

    • One page table entry per page frame

    • A page frame could not belong to two processes at the same time

  • Cannot implement shared pages in an efficient fashion

    • Mach still offers the feature


Final comments
FINAL COMMENTS UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Paper is hard to read but covers a lot of ground

  • You should at least understand

    • mapped files

    • external pagers and memory objects

    • the concept of inheritance

    • copy-on-write

    • the Mach page replacement policy


More about mach
More about Mach UNIPROCESSOR AND MULTIPROCESSOR ARCHITECTURES

  • Mach provides UNIX emulation through either

    • a UNIX emulator in the kernel

    • a UNIX emulation server in user space

  • Even tried to emulate UNIX through a set of specific servers, all in user space

    • GNU’s HURD


ad