Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ncar!ico!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: VM needed for rapid startup
Summary: But consider paging/swapping tradeoff
Message-ID: <5492@ico.ISC.COM>
Date: 26 May 88 23:44:49 GMT
References: <463@cvaxa.sussex.ac.uk> <19322@beta.UUCP>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 29

> One of the things that makes virtual memory LESS useful than it used to be
> is the fact that disk is so slow compared to main memory (and CPU speed).
> If it takes less than the disk access time for your program to execute
> through a whole page of code, a busy multiprocessing environment may spend
> nearly all its time waiting on page faults...

Even if you have an older machine, where the disk:memory speed ratio isn't
quite so horrible, the effect of paging up a program to get it running can
be pretty appalling.  A program will need a certain set of code and data to
get going--for a typical C program, you need the page with crt0, some of the
main program, scattered pieces of libc with stdio, the data for this
stuff...it is common to see a program bring in a dozen pages which are
quite predictable (from a static analysis of the program) in what might as
well be considered random fashion.  That's really expensive--disk transfer
rates are no problem at all compared to seek and rotational latencies.

Two things that ought to be worth trying:
	- Below some size threshold, unless you're really tight on physical
	  memory, you might as well swap the whole program in instead of
	  trying to let it fault itself in.
	- Could some analysis of code be used to derive a set of startup
	  pages for a program?  If so, you could list the pages in the
	  object file somewhere--there's little point in starting up the
	  program until you've got those pages present, and if you pre-
	  load them all at once you can bring them in according to the best
	  order for the disk (including not getting them mixed with
	  requests from other programs running at the same time).
-- 
Dick Dunn      UUCP: {ncar,cbosgd,nbires}!ico!rcd       (303)449-2870
   ...If you get confused just listen to the music play...