🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.arch
Article #2833

Re: Reasons For Large Main Memories

#2833
From: Jon Krueger
Date: Sun, 14 Sep 1986 01:36
64 lines
3769 bytes
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 
Technical Details
Message-ID: <684@ur-tut.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!rochester!ur-tut!tuba
References: <1161@bu-cs.bu-cs.BU.EDU> <8529@duke.duke.UUCP> <672@ur-tut.UUCP> <7418@lanl.ARPA>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!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