> There's lots of work still to be done on the pmap.  Especially if any of the 
> companies come true on producing multi processor boxen (assuming that they do 
> it SMP style, and not hydra style)  Exactly what happens here depends on the 
> implementation of the MP, however the basics should be similair.

IFAICT, the difficulty with MP will be the lack of cache-snooping or other 
processor level techniques for efficiently maintaining cache coherency -- 
all the locks in NetBSD are distributed all over the place, and I see no 
easy way of maintaining coherency other than by putting all such locks in 
uncached pages.  But I'm not an expert in this area -- maybe there are 
tricks that can be played that I've not thought about.

> 
> There's also a PR outstanding on our pmap not doing scheduler locking 
> properly.  Also adding dynamically allocated L1's, currently it's a boot time 
> parameter or compile time parameter for the number of L1's which limits the 
> max number of processes.  There's also the possibility of using pools to hold 
> L1 and L2 tables when not in use.  Which may speed up reallocation etc.
> 
> I've actually been examining other platform's pmap to see which might be best 
> to look at.  Currently alpha looks interesting, (however alpha's have 3 page 
> table level, and some sort of unique id (the ASN))  There's also the i386 mp 
> branch which might be of interest to see how it differs for supporting mp 
> from the mainline branch.
> 

I took a look at several of the pmaps from the different ports.  The alpha 
one is well written, and the i386 one is not at all bad either ;-).  I 
came to the conclusion that the i386 one probably bore the greatest 
similarity to the ARM in terms of the basic features needed (it's main 
differences being three: VAC; emulation of read hits; and managing L1 page 
tables).

R.