Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!lanl!jlg
From: jlg@lanl.ARPA (Jim Giles)
Newsgroups: net.arch
Subject: Re: VERY LARGE main memories: crypt
Message-ID: <7537@lanl.ARPA>
Date: Mon, 15-Sep-86 18:09:23 EDT
Article-I.D.: lanl.7537
Posted: Mon Sep 15 18:09:23 1986
Date-Received: Mon, 15-Sep-86 21:57:13 EDT
References: <1276@bu-cs.bu-cs.BU.EDU>
Reply-To: jlg@a.UUCP (Jim Giles)
Organization: Los Alamos National Laboratory
Lines: 26

In article <1276@bu-cs.bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>
>Am I missing something? What's the huge problem with this hypothetical
>vadvise(CYCLIC)? Isn't it just MRU (most recently used)?
>...
>most recently used page is the one that will be used again the
>furthest in the future and the least recently used is the one that
>will be used soon. Thus, they do hand to hand combat with LRU
>algorithms. Therefore, it seems they want LRU for the text space
>(being as there's no particular reason to believe the text is any
>different than other programs, locality of reference applies) and MRU
>for their (impure) data space (probably LRU for the rest.) ...

The are two thing wrong with this scheme.  1) Suppose that you problem
fails to fit in main memory by only a few page sizes.  The above scheme
will cycle each and every page of the whole data structure into memory
and back out again on every time step.  The knowledgable programmer,
however, can overlay just a few pages and therefore cut down on the
total I/O requirement of the code.  2) As with any built-in VM system,
ALL references to memory must be decoded for page address - which slows
down the memory interface.  This means that all memory traffic is slower
that it would have been without the VM system - even for those codes (or
parts of codes) which don't require the virtual memory.

J. Giles
Los Alamos