On Mon, 25 Oct 1999, Simon Burge wrote:

> This time however (I've double checked) I do think I've found the cause
> of the problem:
...
> 	-       mips_CacheAliasMask = (mips_L1DCacheLSize - 1) & ~(NBPG - 1);
> 	+       mips_CacheAliasMask = (mips_L1DCacheSize - 1) & ~(NBPG - 1);
...
> >From my reading of the comments in mips/pmap.c and the section on cache
> aliasing in "See MIPS Run", it sounds like with the change we're now
> not caching any page that when entered into the physical to virtual map
> table that's virtual address matches any other page that's already in
> the table, instead of just if the cache indexes match.  Does this sound
> right?

  The mips_L1DCacheSize is the correct value - using mips_L1DCacheLSize
results in a value of 0 for mips_CacheAliasMask.  This works anyway on the
DECstations, since they have a secondary cache and detect cache coherency
problems.  The exception handler will fix the coherency by flushing the
appropriate cache lines.

  If mips_CacheAliasMask is 0, then pmap will never inhibit the cache when
entering multiple mappings of the same physical page.  When the correct
mask value is used, it should only be inhibiting the cache on multiple
mappings of a physical page where the virtual addresses result in
different cache indexes.  I saw this happen when I was first getting the
MIPS3 support working on the DECstation:  the multiple mapping of shared
libraries would result in aliased mappings.  When that caused the cache to
be inhibited on those pages, performace was real poor.  If I commented out
the section of code that inhibited the cache and let the cache coherency
exception fix things, performance improved considerably.  Jason then
mentioned the pmap_prefer() feature, which then would map the shared
libraries on cache-compatible boundaries.  With pmap_prefer(), I never saw
any more cache inhibits.

  This was all with the Mach VM.  I suppose it might be possible that with
UVM, this doesn't work the same, and with the bad value for the cache
alias mask, it would never inhibit the cache.  With the correct cache
alias mask, there could be uncached pages occuring.

  I've got some instrumentation in my kernel to check this, and a little
utility to display pmap stats and cache coherency execption stats.  I'm
not seeing any cache inhibits in my 1.4 kernel, but the cache alias mask
is currently 0.  I'll have to either fix the 1.4 kernel or build a
-current kernel and try it out.

--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA