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.

I would like to add support to the pmap API for using these larger
page sizes.

I discussed the issue with Chuq Silvers the other day, and we came
up with a scheme that works roughly like this:

	* pmap exports an array of page sizes, like so:

		vsize_t pmap_page_sizes[];
		int pmap_page_nsizes;

	  The first entry in this array is always the base page
	  size as provided to the VM system in PAGE_SIZE.  The
	  array is sorted in ascending page size order.

	  For the x86 example, you would have:

		vsize_t pmap_page_sizes[] = {
			0x1000,		/* 4K */
			0x400000,	/* 4M */
		};
		pmap_page_nsizes = 2;

	* Some bits in the "prot" argument to pmap_enter() and
	  pmap_kenter_pa() would be used to specify an index into
	  this table specifying the page size to use.  By default,
	  the index will be 0 (if not specified), and thus the
	  base page size will be used.

	  So, using the x86 example again, to map a page r/w
	  using the 4M page size, you would use:

		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).

With this infrastructure in place, it would be pretty short work to
get the devpager using large pages.  Chuq and I also discussed some
ideas for using large pages for other types of mappings (vnode and
anonymous memory), but they still depend on having this infrastructure
in place.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>