PageRenderTime 73ms CodeModel.GetById 14ms app.highlight 56ms RepoModel.GetById 1ms app.codeStats 0ms

/share/doc/papers/newvm/0.t

https://bitbucket.org/freebsd/freebsd-head/
Unknown | 86 lines | 86 code | 0 blank | 0 comment | 0 complexity | fc70d40abfe2e2964ed863301d241aa5 MD5 | raw file
 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
36A New Virtual Memory Implementation for Berkeley
37.UX
38.AU
39Marshall Kirk McKusick
40Michael J. Karels
41.AI
42Computer Systems Research Group
43Computer Science Division
44Department of Electrical Engineering and Computer Science
45University of California, Berkeley
46Berkeley, California  94720
47.AB
48With the cost per byte of memory approaching that of the cost per byte
49for disks, and with file systems increasingly distant from the host
50machines, a new approach to the implementation of virtual memory is
51necessary. Rather than preallocating swap space which limits the
52maximum virtual memory that can be supported to the size of the swap
53area, the system should support virtual memory up to the sum of the
54sizes of physical memory plus swap space. For systems with a local swap
55disk, but remote file systems, it may be useful to use some of the memory
56to keep track of the contents of the swap space to avoid multiple fetches
57of the same data from the file system.
58.PP
59The new implementation should also add new functionality.  Processes
60should be allowed to have large sparse address spaces, to map files
61into their address spaces, to map device memory into their address
62spaces, and to share memory with other processes. The shared address
63space may either be obtained by mapping a file into (possibly
64different) parts of their address space, or by arranging to share
65``anonymous memory'' (that is, memory that is zero fill on demand, and
66whose contents are lost when the last process unmaps the memory) with
67another process as is done in System V.
68.PP
69One use of shared memory is to provide a high-speed
70Inter-Process Communication (IPC) mechanism between two or more
71cooperating processes. To insure the integrity of data structures
72in a shared region, processes must be able to use semaphores to
73coordinate their access to these shared structures. In System V,
74these semaphores are provided as a set of system calls. Unfortunately,
75the use of system calls reduces the throughput of the shared memory
76IPC to that of existing IPC mechanisms.  We are proposing a scheme
77that places the semaphores in the shared memory segment, so that
78machines that have a test-and-set instruction can handle the usual
79uncontested lock and unlock without doing a system call. Only in
80the unusual case of trying to lock an already-locked lock or in
81releasing a wanted lock will a system call be required.  The
82interface will allow a user-level implementation of the System V
83semaphore interface on most machines with a much lower runtime cost.
84.AE
85.LP
86.bp