In the file sys/arch/arm/arm32/pmap.c function pmap_vac_me_user() the
caching atributes for a process are turned off.  The program can be a simple
"hello world" without any process space page sharing and still the caching
attributes for the process pages are disabled.   

My guess would be that the pages should be marked as cacheable until they
are determined to be shared and then at that point in time they would be
marked "uncached".

Kyle

> -----Original Message-----
> From: Colin Cook [mailto:colin@cook-tech.com]
> Sent: Monday, February 03, 2003 9:32 AM
> To: Steve Woodford; Jason R Thorpe
> Cc: tech-kern@netbsd.org
> Subject: RE: PXA250 Xscale and page tables
> 
> 
> Thanks for the education, I think I get the picture. However, 
> I am still
> lost as to the proper fix. Can you guys think of why the 
> pages are being
> mapped to more than one place? I am using 1.6 now and it 
> still happens.
> There is no hard disk on this system, everything is read 
> directly from a RAM
> drive which was decompressed from flash on boot. It's a very 
> basic setup. Is
> there a debug command I can use to find out where the other 
> pages are mapped
> to and who/why allocated them?
> 
> CC :)
> 
> 
> -----Original Message-----
> From: tech-kern-owner@netbsd.org [mailto:tech-kern-owner@netbsd.org]On
> Behalf Of Steve Woodford
> Sent: Sunday, February 02, 2003 4:17 PM
> To: Jason R Thorpe
> Cc: tech-kern@netbsd.org
> Subject: Re: PXA250 Xscale and page tables
> 
> 
> On Sun, 2 Feb 2003, Jason R Thorpe wrote:
> 
> > 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?
> 
> This thread has reminded me about something I have 
> occasionally noticed on
> sh5. While checking the TLB, I have noticed some 
> cache-inhibited mappings
> right at the start of text. (sh5 has a VIVT I$, and a similar "vac me
> harder" type routine in the pmap)
> 
> I previously put this down to a problem in the sh5 pmap, but 
> perhaps there
> is a more general problem here.
> 
> Cheers, Steve
> 
> 
>