Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!caip!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew From: aglew@ccvaxa.UUCP Newsgroups: net.arch Subject: Re: paging Message-ID: <5100132@ccvaxa> Date: Sat, 13-Sep-86 18:49:00 EDT Article-I.D.: ccvaxa.5100132 Posted: Sat Sep 13 18:49:00 1986 Date-Received: Sun, 14-Sep-86 20:12:34 EDT References: <826@hou2b.UUCP> Lines: 35 Nf-ID: #R:hou2b.UUCP:826:ccvaxa:5100132:000:1652 Nf-From: ccvaxa.UUCP!aglew Sep 13 17:49:00 1986 ... > Henry Spencer describes virtual memory as a technique for making ... > the hard limit of physical memory into a soft limit. Right. Consider these hypothetical graphs (I hope these come out - I'm not using tabs): Strictly physical memory system: The cost of doing overlays _/ (Chunked according to interconnectivity _/ of program and data, and accuracy of / predictions) _____________/ Physical Memory Speed Size of Program/Data---> The vertical axis might be program speed or SW development cost. | Virtual Memory System _____________| _____________/ _______________/ (penalty for virtual memory) ___________________________________________ ^ ^ | Physical memory limit | Virtual memory limit For SW development, the penalty for virtual memory is nearly zero (certainly zero for applications, but nonzero for OS, since somebody has to write the memory management software). For execution, however, the virtual memory penalty is appreciable - it may not slow you down, but it will certainly take hardware and floorspace that you might have devoted to something else. The question is, where do most of your applications lie - below the physical memory boundary, or above? - and which ones cause people to buy your system? Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms