Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site lanl.ARPA
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!whuxl!whuxlm!akgua!gatech!seismo!cmcl2!lanl!jlg
From: jlg@lanl.ARPA
Newsgroups: net.arch
Subject: Re: Why Virtual Memory
Message-ID: <33540@lanl.ARPA>
Date: Mon, 18-Nov-85 16:39:39 EST
Article-I.D.: lanl.33540
Posted: Mon Nov 18 16:39:39 1985
Date-Received: Wed, 20-Nov-85 07:58:15 EST
References: <480@seismo.CSS.GOV>, <384@unc.unc.UUCP> <6086@utzoo.UUCP> <240@l5.uucp> <483@unc.unc.UUCP>
Organization: Los Alamos National Laboratory
Lines: 16

Someone made the point that paging causes a gradual degradation in
performance for a code that couldn't fit in memory.  On modern machines
this degradation would not be so gradual.  On a Cray, for example, the
minimum time to transfer one sector from disk (512 64-bit words at 35.4
Mbits) is about a millisecond.  This does not count the average of half
a disk revolution wait or the operatine system overhead.  This amount of
time corresponds to about 100,000 clock cycles.  With several
independent vector units, 100,000 clocks represents a LOT of idle time.
A job that can't fit into memory would probably not be run in a virtual
environment either because of the degradation caused by paging
(production jobs on Crays currently run for several hours to several
tens of hours as it is).  Programmers for Crays and other non-paging
large machines get around the restricted memory with asyncronous I/O.
The last submitter to this discussion complained that he didn't want to
have to do data paging himself - but who else knows what data will next
be needed if the author of the code doesn't?