Xref: utzoo comp.arch:5811 comp.os.vms:7619
Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!cornell!uw-beaver!uw-june!pardo
From: pardo@june.cs.washington.edu (David Keppel)
Newsgroups: comp.arch,comp.os.vms
Subject: Re: Pagefault time
Keywords: Page fault
Message-ID: <5401@june.cs.washington.edu>
Date: 29 Jul 88 17:54:33 GMT
References: <8103@rama.UUCP>
Reply-To: pardo@uw-june.UUCP (David Keppel)
Distribution: na
Organization: U of Washington, Computer Science, Seattle
Lines: 30

>[ Faulting performance on a VAX ]

You can probably figure it out yourself by setting your csh "time"
variable with:

    set time=(5 "%Uu %Ss %E %P (%Xt+%Dds+%Kavg+%Mmax)k %Ii+%Oo (%Fmaj+%Rmin)pf %Wswaps")

The "maj" figure is "major", or i/o-requiring faults, while "min" is
"minor", or recoverable faults.  The "k" figures are wrong in various
combinations on various machines (bugs in undocumented features) so
don't use them.  "u"=user time, "s"=system time, %E is for elapsed
time, and %P is percent of cpu (computed as [s+u]/elapsed).

Page fault times are idle/faults, and idle time is elapsed-(s+u).

Now all you need to do is find a machine where you can allocate more
virtual memory than physical memory (not always easy) and write some
programs that have various kinds of faulting behavior.  One way to do
this is to allocate a huge array (larger than physical memory) and
step through it in page-size increments.  You can compare performance
when the pages are only read, when they are written, etc.
As you get below the physical memory limit the hard fault rate should
drop dramatically.  Soft faults are harder to generate so you may need
to do some algebra to figure out soft rates once you know the hard
rates.

Your tests should probably be done on a lightly-loaded system else
your process will be ready to go after a page fault but will not run
because the CPU is busy.

	;-D on  ( followup reply e-mail, avoid posts! )  Pardo