Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!hc!beta!jlg
From: jlg@beta.UUCP (Jim Giles)
Newsgroups: comp.arch
Subject: Re: VM needed for rapid startup
Keywords: paging virtual-memory speed
Message-ID: <19496@beta.UUCP>
Date: 27 May 88 20:03:37 GMT
References: <463@cvaxa.sussex.ac.uk> <19322@beta.UUCP> <5129@nsc.nsc.com>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 23

In article <5129@nsc.nsc.com>, stevew@nsc.nsc.com (Steve Wilson) writes:
> [...] Also consider that USUALLY the execute-a-page then fault situation
> only occurs at process startup.  This is where the concept of a "working
> set" comes from.  Once that working set of pages is resident in main memory
> the occurance of page faults drop off.  

This is true for many programs, but the 'working set' idea only works
for the code image of most scientific programs.  The data image is often
updated completely for each 'time-step' of a simulation, for example.
Since data is MUCH larger than code these days, this could lead to
constant page faulting.

This problem is an example of the original statement I made on this subject:
when the ratio of CPU speed to disk speed is high, virtual memory is not
as attractive.  The problem is not solved by such schemes as having larger
page sizes or loading more than one page during page fault resolution - the
issue still arises when the CPU gets faster in the next machine generation.
And both these solutions make a page fault even more of a delay for the
program.

The basic issue here is that perhaps there are types of programming
environments that don't benefit from virtual memory - especially if large
memory machines are available.