Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!pyramid!ncr-sd!stubbs From: stubbs@ncr-sd.UUCP (Jan Stubbs) Newsgroups: net.arch Subject: Re: Very large memories Message-ID: <1164@ncr-sd.UUCP> Date: Tue, 9-Sep-86 15:59:43 EDT Article-I.D.: ncr-sd.1164 Posted: Tue Sep 9 15:59:43 1986 Date-Received: Tue, 9-Sep-86 20:49:22 EDT Reply-To: stubbs@ncr-sd.UUCP (0000-Jan Stubbs) Organization: NCR Corporation, San Diego Lines: 45 The issue of virtual memory usage on large memories keeps coming up, so I felt compelled to propose the following as the reasons for using virtual memory in a computer system: 1) The program doesn't fit in the memory, or the job mix doesn't fit but the working set does. This reason may go away as memory sizes increase, unless applications sizes increase at a faster rate, or cpu powers increase such that more jobs or tasks need to be in memory to keep the cpu busy. 2) Memory management hardware usually provides memory protection and automatic relocation (which may improve load time) but these features are available without virtual memory. 3) The real reason for virtual memory (and the one which won't away when memories get big) is that I can quickly load the working set of a large program, execute it, and go on to the next program, while a real memory system might be still loading its program. In fact, I can start executing when the first page gets in, on a properly implemented system where everything is already in paging format. This assumes that the working set is smaller than the program, and that the programmer didn't do some work to only load those pieces of program and data which were needed this time. This kind of programmer work is probably non-productive especially since hardware (and software LRU algorithms) can do it better. Another case peculiar to Unix systems is VFORK. Why duplicate the whole address space when the most likely thing to do next is EXEC, which will clobber the space you just copied? In summary, my guess is that we will continue to pay the cost of virtual memory overhead for a long time yet, for the majority of applications. Jan Stubbs ....sdcsvax!ncr-sd!stubbs 619 485-3052 NCR Corporation 16550 W. Bernardo Drive MS4010 San Diego, CA. 92127