  Tracking Global Page Faults? 
 The Question is:
 
  Dear Wizard,
 
  Some processes on our system make page faults :-). They deal with
RDB with Global Buffer option, so they should produce some quantity of
Global Valid page faults. How can I distinguish between Global Valid
faults (good and expected), page faults from secondary page cache
(not so good, need to adjust WS params) and page faults from page file
(bad) for certain process? I guess I can retrive third item from the
PHD$L_PGFLTIO cell in the PHD. Is it correct?
  And another related question: These processes have unexpected big
(close to WSMAX=PQL_MWSEXTENT) WS sizes. I suspect that the very
Global Valid page faults force system to increment their WS sizes
during AWSA, even though they dont't really need it. These processes
have total page count in WS = 1/2 of WS size but more than WS quota,
and it may be result of proactive memory reclamation (MMG$_CTLFLAGS = 3).
So my question: Do Global Valid page faults affect AWSA process?
  I use OVMS/AXP 6.2
 
  Thank you.
 
  Valentin Likoum
 
 
 
 The Answer is:
 
  There is no way to distinguish -- on a per-process basis -- how a
  particular soft page fault was resolved.  The fault can be demand-zero
  (DZRO), global valid, from a transition list, or a collided page fault.
  Note too that page fault I/Os -- indeed accumulated in phd$l_pgfltio --
  often read more than 1 page, in an effort to reduce subsequent additional
  pages faults.
 
  Now the more interesting question: why do you believe that global valid
  faults are "good" or "ok"?  If a process incurs many of these, the AWSA
  logic can and should increase the working set.  This has neglible memory
  costs as the same page is already used by another process, though it does
  require an element in the process working set list.  So, yes, if Oracle
  Rdb uses substantial quantities of global pages for database caches, the
  OpenVMS Wizard would expect Oracle Rdb processes accessing these caches
  would use large(r) working sets.
 
  The size of entries in the working set -- the number of entries in the
  list -- is present in phd$l_wssize.  Some/many of these entries may not
  be currently in use.  For the total number of current pages, you would
  have to add pcb$l_ppgcnt and pcb$l_gpgcnt.  If this value is much less
  than phd$l_wssize, then the process has been trimmed back.
 
