Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!ur-tut!tuba From: tuba@ur-tut.UUCP (Jon Krueger) Newsgroups: net.arch Subject: Re: Reasons For Large Main Memories Message-ID: <684@ur-tut.UUCP> Date: Sat, 13-Sep-86 21:36:59 EDT Article-I.D.: ur-tut.684 Posted: Sat Sep 13 21:36:59 1986 Date-Received: Sat, 13-Sep-86 23:40:04 EDT References: <1161@bu-cs.bu-cs.BU.EDU> <8529@duke.duke.UUCP> <672@ur-tut.UUCP> <7418@lanl.ARPA> Reply-To: tuba@ur-tut.UUCP (Jon Krueger) Organization: Univ. of Rochester Computing Center Lines: 64 Keywords: virtual memory appropriate In article <7418@lanl.ARPA> jlg@a.UUCP (Jim Giles) writes: >The CAD system should be able to function perfectly well without its entire >working set...It should only read in that part of the data which is required >to satisfy the user's request...By making this paging a responsibility of the >CAD system instead of the hardware, you allow those applications which don't >need virtual memory to proceed without the overhead of a slow memory >interface. I can arbitrarily divide up applications into types as follows: 1. applications which fit into physical spaces and available physical memory sizes 2. applications which can trivially manage their own spaces, with acceptable development and maintainence costs, which achieve comparable levels of performance to their virtual memory equivalents 3. applications which can trivially manage their own spaces, with acceptable development and maintainence costs, which achieve higher levels of performance than their virtual memory equivalents 4. applications which can be made to manage their own spaces, but cost more or perform less than their virtual memory equivalents 5. applications with no known algorithms to manage their own space, which could conceivably by made to do so at some cost in development or performance Applications of type 1 and 2 don't require large spaces, either physical or virtual. You point out that they would run faster without virtual address translation. You've got me there. For a given space into which an application fits, it will run faster if the space is physical. If your applications don't require any other benefits of virtual memory, such as memory protection or easy relocation, you're free to run them in your favorite physical space. You can now buy small physical spaces cheaply and easily. The demands of such applications are not a significant architectural problem in 1986. I invite anyone to submit examples of type 3. I haven't got any, but I suspect there are a few. Applications of type 4 and 5 require or benefit from large spaces. It has been shown elsewhere that virtual spaces provide the same spaces as physical ones, at 10% of the cost for 90% of the performance. The problem seems to be that you're running applications of type 1 and 2 on systems designed to handle types 4 and 5. I suggest you move them to small, cheap, systems. If you don't need the benefits of virtual memory, you shouldn't be asked to pay its costs. Has anyone seen a multiprocessor scheme where some processors maintain physical spaces and others virtual? I'll take one where the kernel moves each image to the first free processor that supports an appropriately sized space, where the larger spaces are more likely to be virtual, and the smaller ones physical. Anyone heard of such a beast? -- jon -- --> Jon Krueger uucp: {seismo, allegra, decvax, cmcl2, topaz, harvard}!rochester!ur-tut!tuba Phone: (716) 275-2811 work, 235-1495 home BITNET: TUBA@UORDBV USMAIL: Taylor Hall, University of Rochester, Rochester NY 14627