jack@cwi.nl (Jack Jansen) (05/25/88)
Two idle thoughts I had on paging: I have the feeling that a lot of programs will go through a fixed sequence of page faults during startup. This is especially true of programs like editors, that will always read your startup script and execute numerous commands before finally entering interactive mode. Now, it seems it would be worthwile to build a list of the first, say, 50 pages in the order of need, and attach that to the program so that the OS can immedeately start paging in the next page as soon as it has started the program. This should reduce latency, and possibly forestall future page faults. Would this be worthwile? Has any work in this direcction been done? Second thought: in a segmented architecture it would by nice to do paging by the segment, in stead of per page. This way, you can put each module (code+data) into a segment of it's own, and you'll only experience one page fault when you first call printf(), in stead of the current two or three. -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
kerns@mfci.UUCP (A BBoard) (05/26/88)
In article <338@piring.cwi.nl> jack@cwi.nl (Jack Jansen) writes:
=
=Two idle thoughts I had on paging:
=
=I have the feeling that a lot of programs will go through a fixed
=sequence of page faults during startup. This is especially true of
=programs like editors, that will always read your startup script and
=execute numerous commands before finally entering interactive mode.
=
=Now, it seems it would be worthwile to build a list of the first,
=say, 50 pages in the order of need, and attach that to the program so
=that the OS can immedeately start paging in the next page as soon as
=it has started the program. This should reduce latency, and possibly
=forestall future page faults.
=
=Would this be worthwile? Has any work in this direcction been done?
Data General's AOS/VS allows a user to specify specific pages or ranges of
pages to prepage on a program-by-program basis. You can also specify the page
clustering.
I have actually used this facility to make text editors start up faster.
----
Dan Kerns kerns@multiflow.com or mfci!kerns
Multiflow Computer (203)488-6090daveb@geac.UUCP (David Collier-Brown) (05/30/88)
In article <338@piring.cwi.nl> jack@cwi.nl (Jack Jansen) writes:
=I have the feeling that a lot of programs will go through a fixed
=sequence of page faults during startup. This is especially true of
=programs like editors, that will always read your startup script and
=execute numerous commands before finally entering interactive mode.
=
=Now, it seems it would be worthwhile to build a list of the first,
=say, 50 pages in the order of need, and attach that to the program so
=that the OS can immedeately start paging in the next page...
A side point: one should do such with at least a semi-automatic facility,
like a profiler. A facility to automatically collect page-fault lists for a
particular program and turn them into preload lists at a later date
would be useful, and conceptually straightforward:
for the first N executions:
collect the first 100 page faults
for the N+1th execution
find the longest common subsequence
make that the preload list.
--dave
--
David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb
Geac Computers Ltd., | "His Majesty made you a major
350 Steelcase Road, | because he believed you would
Markham, Ontario. | know when not to obey his orders"gillies@uiucdcsp.cs.uiuc.edu (06/01/88)
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}