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}