Re: pmap_extract(9) (was Re: xmd(4) (Re: XIP))

[Matt Thomas <matt%3am-software.com@localhost>]

On Nov 8, 2010, at 8:07 AM, Masao Uebayashi wrote:

> On Mon, Nov 08, 2010 at 10:48:45AM -0500, Thor Lancelot Simon wrote:
>> On Mon, Nov 08, 2010 at 11:32:34PM +0900, Masao Uebayashi wrote:
>>> 
>>> I don't like "it's MD, period" attitude.  That solves nothing.
>> 
>> We've had pmaps which have tried to pretend they were pmaps for some
>> other architecture (that is, that some parts of the pmap weren't
>> best left MD).  For example, we used to have a lot of pmaps in our
>> tree that sort of treated the whole world like a 68K MMU.
>> 
>> Performance has not been so great.  And besides, what -are- you going
>> to do, in an MI way, about synchronization against hardware lookup?
> 
> Do you mean synchronization among processors?

No.  For instance, on PPC OEA processors the CPU will write back to
the reverse page table entries to update the REF/MOD bits.  This
requires the pmap to use the PPC equivalent of LL/SC to update PTEs.

For normal page tables with hardware lookup like ARM the MMU will 
read the L1 page table to find the address of the L2 page tables 
and then read the actual PTE.  All of this happens without any sort
of locking so updates need to be done in a lockless manner to have
a coherent view of the page tables.

On a TLB base MMU, the TLB miss handler will run without locking 
which requires an always coherent page lookup (typically page table)
where entries (either PTEs or page table pointers) are updated using
using lockless primitives (CAS).  THis is even more critical as we
deal with more MP platform where lookups on one CPU may be happening
in parallel with updates on another.

This doesn't mean that the pmap can't be made more MI (for instance
I have the mips and ppc85xx pmaps sharing a lot of code but still
have MD bits to handle the various machine dependent bits).  But
going completely MI is just not possible.