stuart@rennet.cs.wisc.edu (Stuart Friedberg) (12/05/88)
I received a number of wildly inconsistent answers to my question of
last week. My thanks to all who responded. The credible responses can
be summarized as follows:
a) The 4/110 doesn't have a real cache. Instead, it has a static column
RAM setup that usually gives similar performance advantages.
There are multiple memory banks, each supplying several physical
pages (columns).
b) A performance hit analogous to *repeated* cache misses occurs when
two frequently accessed physical pages fall within the same memory
bank.
c) By changing the *size* of the statically allocated array, I was
causing a different set of physical *addresses* to be used for
dynamically allocated memory. Apparently this happens even if
the unused statically allocated pages are never referenced.
(This seems odd to me. My guess is that SunOS 4.0 physically
allocates static data when possible, and doesn't try to demand page
it in.)
d) Changing the physical pages used for dynamically allocated memory
had the side effect of reducing the "misses" between dynamically
allocated memory and at least one of the three other logical
memory segments: code, static data, and/or stack.
(I have been told that SunOS 4.0 tries to avoid such clashes
between logical code and data pages by a careful choice of
physical pages.)
So, the anomaly I noted is due to the Sun-4/110 memory system
specifically. In my particular case, what *appears* to be a dubious
operating system optimization was also required to tickle the anomaly.
Stu Friedberg stuart@cs.wisc.edu