In some email I received from Jason R Thorpe, sie wrote:
> Several platforms support multiple page sizes.  Examples are
> the i386, which has 4K and 4M pages, the ARM which has 4K,
> 64K, and 1M pages, and the MIPS which has 4K, 8K, 16K, ... pages.

What about sparc or ultrasparc?  I've seen recent Solaris9 stuff on
their public web pages saying they now support this.

[...]
> 		pmap_enter(pmap, va, pa,
> 		    VM_PROT_READ|VM_PROT_WRITE|PMAP_PAGESIZE(1), 0);
> 	    or
> 		pmap_kenter_pa(va, pa,
> 		    VM_PROT_READ|VM_PROT_WRITE|PMAP_PAGESIZE(1));
> 
> 	* The array is exported for the benefit of the upper layer
> 	  VM code to determine which VA alignment is required in order
> 	  to use larger pages.  When mappings are established, the
> 	  VM system can determine which alignments to try by starting
> 	  at pmap_page_sizes[pmap_page_nsizes - 1] and working backwards
> 	  until it reaches index 0 (the base page size).

This is fine if you want to provide hints, but what about something like
VM_PMAP_BESTFIT?  ie. make it search forwards rather than backwards so
that it can be used without particular knowledge of what's in that array.
It strikes me that providing hints is going to be somewhat architecture
dependant, too, as PMAP_PAGESIZE(1) might be 4M for i386 but 4M might
be PMAP_PAGESIZE(5) on some other architecture (hypothetical).

Also, please excuse my ignorance on pmap & va, can it used mixed allocation
to fill a request?  So that if I ask for (say) 4.5MB of va it looks and says
"ooh, I can do that with 1*4MB and 128*4k and get a perfect fit!" rather
than doing 2*4Mb and wasting 3.5MB of virtual memory?  At what point does
it decide to waste VA for pmap entries?  (Research paper on this?)

Darren