for anyone who hasn't been involved in this discussion yet, I'll give
some background.  the initial goal of Matt Thomas's ppc pmap changes
was to add support for large-memory systems, since the existing pmap
had some limitations there.  after he got into that, he found various
performance deficiencies and kinda went wild and ended up rewriting
almost all of the code.  so that's where this thing came from.
  
the most important changes in NEWPMAP are:

 - use a pool for the PTE overflow entries, and put the first 256 MB
   of physical memory on a separate freelist which the PTE overflow
   entries are allocated from, so that they are always addressible
   via BAT0.

 - use one structure to represent both the PV entry and the overflow entry,
   whereas the old pmap used separate structures for these two items.

 - improve the selection of segment numbers to greatly reduce the
   probability of collision in the PTEG hash table.


there are also several open PRs for bugs in the old pmap which are not
present in the new pmap:

	13521	CPU-bound process gets less and less CPU, RES increases
	14904	PowerPC w/o NEWPMAP deadlocks if faulting on kernel map ...
	15232	ffs_sync writes out read-only pages to disk

the new pmap is also about 2% faster than the old pmap for doing
"make release", most likely because of the improved hashing.

for all of these reasons, it would be good to enable NEWPMAP by default
for the next release.  does anyone know of any reason why we shouldn't
do this?  does anyone have any other questions about the new pmap?

if there's no objection, I'll make NEWPMAP the default on March 9
by replacing the NEWPMAP option with an OLDPMAP option, so that
kernels will get the new pmap by default but can select the old pmap
with "options OLDPMAP".