Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!decvax!decwrl!amdcad!amd!pesnta!peora!joel
From: joel@peora.UUCP
Newsgroups: net.arch
Subject: Re: Reasons For Large Main Memories
Message-ID: <2448@peora.UUCP>
Date: Mon, 22-Sep-86 18:19:29 EDT
Article-I.D.: peora.2448
Posted: Mon Sep 22 18:19:29 1986
Date-Received: Tue, 23-Sep-86 18:51:17 EDT
References: <1161@bu-cs.bu-cs.BU.EDU> <8529@duke.duke.UUCP> <672@ur-tut.UUCP> <7418@lanl.ARPA> <684@ur-tut.UUCP>
Organization: Concurrent Computer Corporation, Orlando, Fl
Lines: 25
Keywords: virtual memory appropriate

>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
>--> Jon Krueger

	I haven't seen it done on a processor basis, but I've seen it
	done on a task by task basis. On our OS32MT operating most tasks
	run in real memory, but you can specify a virtual task manange-
	ment option at link time. All tasks run with address relocation
	hardware enabled, while virtual tasks actually have routines
	to handle page faults linked in. This means that the size of
	the working set of the task is fixed at load time, rather
	than sharing a common pool with other virtual tasks. There is
	an additional problem in that the page size is a rather
	unwieldy 64KB.

	Also on MVS back on IBM mainframes there is a V=R where the
	whole task is loaded into a contiguous chunk of real memory.
	This was generally used with small tasks with critical
	performance.
-- 
     Joel Upchurch @ CONCURRENT Computer Corporation (A Perkin-Elmer Company)
     Southern Development Center
     2486 Sand Lake Road/ Orlando, Florida 32809/ (305)850-1031
     {decvax!ucf-cs, ihnp4!pesnta, vax135!petsd, akgua!codas}!peora!joel