Request for help with paging.

[whuts!davel%att.att.com@RELAY.CS.NET]

We have written a system which appears to have a grave difficulty with
thrashing in the paging system.  When freshly loaded, the system
appears to spend perhaps 10% of its process time in the paging system,
but after about four hours of continuous running, paging system time
increases dramatically to 80% or so.  These results have been confirmed
with both the TIME macro and the Metering system.  According to the
metering system, there is no small subset of functions responsible for
most of the paging.  So far, we have found that our efforts to increase
locality of reference by using many areas have yielded minimal improve-
ment.  We had expected the problem to be solved by the use of areas;
we have a physical memory of 6MW, each area is smaller than 
4MW or so for the first five hours of the run, and references between 
areas should be uncommon.  For reference, we are using a 3675 with a swap
space of 150MW, but using a smaller swap space (75MW) seems to have no
effect on performance.
1. What is the paging scheme used by the 3600-series (e.g.,
least-recently-used), anyway? Software support doesn't know and has had
some difficulties getting a hold of a developer who does.
2. Has anyone had similar difficulties with paging?  How did you solve
them?
3. We are particularly alarmed by the fact that increasing the
number of areas (and, we believe, increasing locality of reference)
has had so little impact.  Does anyone know of a way to find out
how much physical memory is devoted to each area?  Is there any way
to measure locality of reference directly, such as counting the
number of pointer references across area boundaries?

David Loewenstern
<davel@whuts.att.com; backbone!{moss || ihnp4}!whuts!davel>
AT&T Bell Laboratories
14B-253
Whippany, NJ 07981
201-386-6516