On Sun, Feb 02, 2003 at 12:48:19AM -0700, Colin Cook wrote:

 > Ok, Sorry I'm slow, are you saying that the I-Cache deals with virtual
 > addresses only? So if 2 VA's mapped to the same PA, you could write to the
 > first and it would sit in the cache for that address but VA 2 would not see
 > it? Doesn't the caches implement some type of snoop-invalidate protocol?
 > (Again sorry for foolish questions, I don't know ARM all that well).

On ARM, yes, the I$ and D$ deal only with virtual addresses.  They do
not implement a snooping protocol.  The OS is reponsible for maintaining
the coherency, which is why we must disable caching of that pages in those
situations.

 > 1) We are dealing with Read Only code pages, So what if it's only in 2
 > places.

Right, I wasn't clear enough in my first message about this .. of all of
the multiple-mappings are read-only, then that's disabling of the cache
is not neccesary.  However, if *just one* writable mapping for that page
exists, then caching must be disabled for all mappings.

 > 2) How did it get in 2 places in the first place. This is nothing more than
 > a simple application. Does NetBSD make a habit out of duplicating CODE
 > pages.
 > 3) I could totally see your point if we were dealing with a shared data area
 > between kernel and user space. But we are dealing with the executable code
 > of an application.

Well, when pages are read in from backing store (disk, NFS, whatever), the
virtual memory system creates a writable mapping of that page in order to
do the I/O to it.

In an older version of NetBSD's UBC (unified buffer cache), these writable
mappings were kept around in case they were needed again later, lazily
replaced when new UBC mappings were needed.  This led to degraded performance
on VIVT platforms (like the ARM) because there was a kernel-writable mapping
of these pages.

This was fixed, however, in Jan 2002, and the fix was thus in the
1.6 release.  What version of NetBSD are you using?

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>