Path: utzoo!attcan!uunet!husc6!bloom-beacon!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uiucdcsp!gillies
From: gillies@uiucdcsp.cs.uiuc.edu
Newsgroups: comp.arch
Subject: Re: Random thoughts on paging.
Message-ID: <76700028@uiucdcsp>
Date: 1 Jun 88 04:23:00 GMT
References: <338@piring.cwi.nl>
Lines: 36
Nf-ID: #R:piring.cwi.nl:338:uiucdcsp:76700028:000:1587
Nf-From: uiucdcsp.cs.uiuc.edu!gillies    May 31 23:23:00 1988


On Xerox DLions, you can package your code into chunks to get more
performance.  This was necessary on a machine with an 80ms access-time
8" disk, and a processor barely as fast as a VAX 750.  After compiling
and binding a binary module, you run it through the "packager" which
arranges procedures into clumps of pages swapped in by a single page
fault.

For instance, I once package a mail service (35 modules), and there
were packs for (oversimplifying)

Startup [ 50 procedures, 20 pages ]
Hot     [ 20 procedures, 10 pages ]
Warm    [ 35 procedures, 30 pages ]
Cold    [ 100 procedures, 60 pages ]
ExceptionHandlers [ 15 pages ]
UserAdministration [ 100+ procedures, 80 pages ]

I used a code profiler to decide how to package the server program,
and wrote something to combine the profiling and packaging information
together.  With the information in one file, it was easy to look at an 
old packaging specification (a certain procedure in "Hot" for instance),
and notice it was only called 5 times in twenty hours.  This might
suggest moving the procedure to "Cold".  

The result was that the mail service averaged perhaps 5 paging events
per hour, mainly keeping the Hot and Warm packs in memory.  Without
packaging, it would page every few seconds.  (Many customers would run
half a dozen other services on the same machine).

Packaging is a bit more complex that what you suggested (a way to
(pre)page quickly at startup), but I believe it is a more general and
can serve the same purpose.

Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
            {gillies@p.cs.uiuc.edu}