Article View: net.arch
Article #2833Re: Reasons For Large Main Memories
From: Jon Krueger
Date: Sun, 14 Sep 1986 01:36
Date: Sun, 14 Sep 1986 01:36
64 lines
3769 bytes
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!tubaReferences:
<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