Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.arch
Subject: Re: Very large memories
Message-ID: <3390@umcp-cs.UUCP>
Date: Fri, 12-Sep-86 22:26:30 EDT
Article-I.D.: umcp-cs.3390
Posted: Fri Sep 12 22:26:30 1986
Date-Received: Sat, 13-Sep-86 00:43:01 EDT
References: <1164@ncr-sd.UUCP> <2383@peora.UUCP>
Organization: Computer Sci. Dept, U of Maryland, College Park, MD
Lines: 30

>In article <1164@ncr-sd.UUCP> Jan Stubbs writes:
>>3) The real reason for virtual memory (and the one which won't
>>away when memories get big) is that I can quickly load [a]
>>working set of a large program ...

In article <2383@peora.UUCP> joel@peora.UUCP (Joel Upchurch) replies:
>... but it seems to me that you'll use up [the faster startup] and
>a lot more in page faults.  Since you are reading the program
>piecemeal into virtual memory you are going to be a lot slower
>because of the extra seek and rotational delays. It is sort of like
>a guy driving on a surface street, instead of going over and getting
>on the freeway. You get started faster, but you hit all those
>traffic lights. The only case that is valid is if the overwhelming
>majority of the pages in the program are never referenced.

This analogy is flawed.  This would be true if one other thing were
also true.  The delay produced by paging has to be noticeable when
compared to other delays in the system.  The primary delay in the
system is likely to be the user, and his delay is likely to be on
the order of seconds, not milliseconds: thus the paging is lost in
the noise.

This depends, of course, on the exact characteristics of the system.
If nothing can be displayed until the entire program is loaded,
that program should not be paged in piecemeal.  This is exactly
what the BSD NMAGIC format is for.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu