share/doc/papers/newvm/0.t

   1 .\" Copyright (c) 1986 The Regents of the University of California.
   2 .\" All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\" 3. All advertising materials mentioning features or use of this software
  13 .\"    must display the following acknowledgement:
  14 .\"     This product includes software developed by the University of
  15 .\"     California, Berkeley and its contributors.
  16 .\" 4. Neither the name of the University nor the names of its contributors
  17 .\"    may be used to endorse or promote products derived from this software
  18 .\"    without specific prior written permission.
  19 .\"
  20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  23 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  30 .\" SUCH DAMAGE.
  31 .\"
  32 .\"     @(#)0.t 5.1 (Berkeley) 4/16/91
  33 .\"
  34 .rm CM
  35 .TL
  36 A New Virtual Memory Implementation for Berkeley
  37 .UX
  38 .AU
  39 Marshall Kirk McKusick
  40 Michael J. Karels
  41 .AI
  42 Computer Systems Research Group
  43 Computer Science Division
  44 Department of Electrical Engineering and Computer Science
  45 University of California, Berkeley
  46 Berkeley, California  94720
  47 .AB
  48 With the cost per byte of memory approaching that of the cost per byte
  49 for disks, and with file systems increasingly distant from the host
  50 machines, a new approach to the implementation of virtual memory is
  51 necessary. Rather than preallocating swap space which limits the
  52 maximum virtual memory that can be supported to the size of the swap
  53 area, the system should support virtual memory up to the sum of the
  54 sizes of physical memory plus swap space. For systems with a local swap
  55 disk, but remote file systems, it may be useful to use some of the memory
  56 to keep track of the contents of the swap space to avoid multiple fetches
  57 of the same data from the file system.
  58 .PP
  59 The new implementation should also add new functionality.  Processes
  60 should be allowed to have large sparse address spaces, to map files
  61 into their address spaces, to map device memory into their address
  62 spaces, and to share memory with other processes. The shared address
  63 space may either be obtained by mapping a file into (possibly
  64 different) parts of their address space, or by arranging to share
  65 ``anonymous memory'' (that is, memory that is zero fill on demand, and
  66 whose contents are lost when the last process unmaps the memory) with
  67 another process as is done in System V.
  68 .PP
  69 One use of shared memory is to provide a high-speed
  70 Inter-Process Communication (IPC) mechanism between two or more
  71 cooperating processes. To insure the integrity of data structures
  72 in a shared region, processes must be able to use semaphores to
  73 coordinate their access to these shared structures. In System V,
  74 these semaphores are provided as a set of system calls. Unfortunately,
  75 the use of system calls reduces the throughput of the shared memory
  76 IPC to that of existing IPC mechanisms.  We are proposing a scheme
  77 that places the semaphores in the shared memory segment, so that
  78 machines that have a test-and-set instruction can handle the usual
  79 uncontested lock and unlock without doing a system call. Only in
  80 the unusual case of trying to lock an already-locked lock or in
  81 releasing a wanted lock will a system call be required.  The
  82 interface will allow a user-level implementation of the System V
  83 semaphore interface on most machines with a much lower runtime cost.
  84 .AE
  85 .LP
  86 .bp