VMDesignDecisions.tioga January 17, 1983 4:14 pm Some Design Assumptions and Decisions for a New Virtual Memory System A read/write file system model is to be used We have some experience with the mapped file model and believe that it does not offer any significant advantages over the more traditional read/write model for file access. A mapped file approach may reduce the total amount of backing storage required for virtual memory, but the code to implement it seems to be more complex. A read/write model tends to require more backing storage but reduces or eliminates some sources of implementation complexity (e.g., residency requirements/strategies for backing storage address tables, swap buffers, file size modification) The entire virtual memory can be backed by a single disk file The virtual memory is backed by a large, anonymous disk file. Our disks are large enough to accommodate a 24-bit address space (64K pages of backing storage; about 32 megabytes) on a Dorado and a 22-bit address space (16K pages; 8 megabytes) on a Dolphin. (22 bits should be acceptable on a Dandelion with an SA4000 or Quantum disk; perhaps even 23 bits would fit.) In principle, the mapping from virtual page number to disk page number is a simple numerical calculation. In practice, one cannout assume that it will be possible to allocate a file of 16K-64K pages completely contiguously, since most disks have one or more bad spots. Thus, the mapping will be implemented with a (presumbably short) run table. Coarse-grain synchronization of virtual memory operations is acceptable A single monitor will synchronize all virtual memory manipulations. In particular, the monitor will be held during fault-handling. This means that during an I/O transfer initiated by either a page-fault or a swapout, no access to the virtual memory data structures will be permitted. This eliminates the need for selective locking of virtual address ranges at the expense of some potential parallelism. We believe the actual lost parallelism will be slight. Simple "seek-ahead" provides adequate I/O overlap with fault-handling Page faults are handled in a simple, synchronous way. There is a single PageFault process that is awakened by the occurrence of a fault, calls into the virtual memory system to swap in the requested page, and waits for the I/O to complete. No queuing facilities are provided at the disk level. A simple "seek-ahead" scheme is employed: when a disk request is submitted, it may include a disk address to which a seek is to be performed at the completion of the requested operation. The idea is that, if the PageFault queue has multiple requests in it, the disk address for the second faultee's page is supplied when the first faultee's page is requested. Therefore, when the I/O transfer completes, the software can restart the first faultee and initiate the I/O for the second faultee while the disk is already seeking to the required address. Since all of virtual memory is backed by storage on a single disk, there is no opportunity for overlapping transfers with each other. "Seek-ahead" would seem to provide most of the concurrency necessary for adequate performance. Swap units are not a fundamental requirement Pilot's swap unit notion introduces substantial complexity at the level of the swapper. We propose that the lowest level swapping facilities traffic in intervals of virtual memory, but that the PageFault process, at least initially, only request single pages at a time. Should it become useful to do so, additional data structures can be provided to permit the PageFault process to request appropriate swap units. Multiple drives must be supported The disk facilities must be able to support overlapped transfers to multiple drives, since this will be an important performance consideration for Alpine. However, the virtual memory system has no need for this facility; it is provided at the "disk channel" level. A "real memory only" version of the virtual memory system is useful It is useful to be able to write utility programs that massage the disk (e.g., formatter, scavenger) using the same virtual memory system as one uses for regular programs. The only difference is that there is no presumption that backing storage is available, and consequently the virtual memory system is constrained to operate within the available real memory and without swapping. This is the UtilityPilot model. Such a facility naturally falls out of the proposed design. Cedar "safe" storage should be available at the lowest possible level Adequate functionality should be provided in the virtual memory system to permit the file system to be a Cedar program. This simplifies the task of writing the file system and, in conjunction with the "real memory only" version of the system, permits utility programs to be Cedar programs as well, and hence more easily maintained.  "Cedar" styleIbodysKItitleEIhead,KrM=KmKMGKMEKM,KM!KMCK=MEK,