Jason,

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

1) We are dealing with Read Only code pages, So what if it's only in 2
places.
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.

I am not looking to get into a fight with NetBSD, I just want my program to
run fast. Just tell me the right way to get the program to run out of
I-Cache.

Thanks.

CC :)




-----Original Message-----
From: Jason R Thorpe [mailto:thorpej@wasabisystems.com]
Sent: Saturday, February 01, 2003 11:51 PM
To: Colin Cook
Cc: tech-kern@netbsd.org
Subject: Re: PXA250 Xscale and page tables


On Sat, Feb 01, 2003 at 10:13:55AM -0700, Colin Cook wrote:

 > Sorry, There *is* something grossly wrong with ALL arm32 based NetBSD
code.
 >
 > ptes[arm_btop(npv->pv_va)] &= ~L2_S_CACHE_MASK in pmap.c
 >
 > It is removing the C bit from application CODE space. We have removed
this
 > line and our app now runs 10X faster.

The ARM uses a virtually-indexed,virtually-tagged cached.  Making the page
un-cached is required if you have multiple mappings of the same physical
page within an address space (either 2 mappings in the same proc or a proc
mapping and a kernel mapping for the same page), thus causing an
incompatible
cache alias, leading to Bad Things.

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