> On Wednesday 14 February 2001  9:36 pm, Richard Earnshaw wrote:
> > > 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.
> 
> Isn't that what SWP is all about (in terms of locking?)  Certainly it's the 
> example used in the ARM ARM as being the basis for locks.  (although the 
> example given scares me as it could do some sort of scary deadlock, as it 
> doesn't use SWP for the final right back to the lock which could get 
> buffered, I'm probably missing something there though :)

The ARM ARM says that SWP only gives SMP semantics if used on uncached 
memory.  On cached memory the only guarantee is that to the processor 
executing the instruction the operation occurs atomically (which makes it 
useful as a thread interlock in a user process).  AFAICT the implication 
with the scattered placement of locks throughout the kernel is that most 
pages in the kernel would have to be mapped uncached (either that or we 
will have to put in some kind of indirection to a "locks" page).


> 
> Does the Xscale contain any extensions to help with SMP (I've not had time to 
> look over the specs)?  Some kind of MP is planned with the use of xscale for 
> risc-os.

Haven't read them in that much detail either.

> 
> > > 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).
> 
> I believe that the arm one was originally based on the i386 one from a long 
> time ago, it's been rewritten/reworked at some point though.

Indeed.  But I think Chuck Cranor (sorry if I've got the attribution 
wrong) rewrote it almost from the ground up.

R.