Request for help with paging

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

Sorry about the delay; mailing glitch.
From: jasper.scrc.symbolics.com!DLA (David L. Andre)
>    Date: Tue, 14 Mar 89 20:08:41 EST
>    From: whuts!davel@att.att.com
>
>    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.

>Sounds to me like the working set of your application increases over time.
>Perhaps you have a data structure which references lots of objects which would
>otherwise be garbage?

Please reread the starred paragraph below.  Actually, our system
references fewer objects with time (since it takes more time to reference
them, and our system is constrained to return a result within a fixed 
time).

*					  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.  

>I am curious on why you think fragmenting memory with lots of areas will improve
>locality of reference?

The idea, from my cursory reading of book 8, is to improve locality
of reference by putting objects *which reference each other frequently*
into the same area.  We believe we had done that.  No, of course just
randomly assigning objects to areas wouldn't improve paging performance.
   
>	   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?

>Have you tried using the metering interface to see what is causing the page
>faults?  Have you tried documented functions to examine areas such as ROOM and
>DESCRIBE-AREA?  You can discover things about cross-area references using
>mouse-middle and SYS:%AREA-NUMBER.

Please reread the starred paragraph above.

We have also used room, etc.  I am at a loss as to how using ROOM will
tell us anything.  As far as I can tell, ROOM can show how many words
are in each area. That is, it offers no more information than
the Peek system's Areas screen. We need to know what is in *physical* 
memory, and how structures are organized by *page*.

Since I posted this request, I found out about the undocumented
function SI:WITH-PAGE-TRACE, which appears to be somewhat useful, 
although I would appreciate some assistance in using it and interpreting
the results.

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