> With it being a bank holiday this weekend (I think it's a bankholiday...) I'm 
> thinking of getting on and playing with the pmap.c, however I'm just 
> wondering if this is still needed and what features need to be allowed for?
> 
> Current list:
> Has to be fast

But of course.

> Support the scheduler lock protocol (once I actually find out what that is)

:-)  And then fix the open PR that's related to this...

> Make it SMP safe (hard to test, but we should be in case someone ever does an 
> SMP based arm box)

Somewhat pointless at this time, particularly if it will impact 
performance.  Until the models for cache coherency on SMP ARM systems are 
defined it isn't really sensible to consider this (IMO).

> Make L1 tables for processes dynamic, IE get rid of the 256 hard limit and 
> other static limits around the place.

Always sensible to avoid hard limits if possible.

> Make use of pools where possible.

Sounds good.

> Be capable of doing some of the cleanup functionality.

As always...

> 
> Other suggestions.  (Note I'll be rummaging around other platform pmap's to 
> see how things are done)

Make use of the new pmap_update() calls that Jason has added to defer 
options when possible until they are really needed (hopefully when the 
pmap in question isn't the current one).  Build work lists when we can and 
then manage them during the update calls.

Investigate caching the L1/2 tables to improve performance.  May require 
restructuring most of the code...

Look at the way i386 pmap organises things -- it should be possible to 
significantly reduce the number of calls to pmap_pde/pmap_pte (which is 
currently huge)

I did send you my patches that I already have, didn't I?

R.