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