> ARM has 4 subpages too isn't it?

yes and no....
The sub-pages don't have enough bits to be useful - I can't remember
the exact info, but I think there are only 2 bits per sub page.....
Can you also map 4 pages with one TLB? I don't have the ARM book here,
I only mapped 1M and 4k pages when I was setting up the arm mmu.

> will be an EXCELLENT idea. for example large 20.5MB file could be mapped
> as 2*4MB+ 640*4K on i386 or 20*1M+8*64k on ARM
> 
> it would make GREAT speedup.

One big benefit is that you use a lot less TLB entries, cutting down
on the number of page table walks.  Never mind the memory saved by
not having lower level page tables.

The cost of faulting in the entire 4Mb might slow thing down - especially
if you are doing (generally) sequential accesses and some 'look ahead'
scheme gets the next page in before you fault on it... 

> 
> > 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
> 
> what about mapping regular data this way?

One problem, not to be overlooked, is that you need to find contiguous
physical memory to map the 'large' page.

You also have to swap it in/out as a single unit.

This means it is (probably) only really advantagous to use very large pages
for items that are going to be resident (eg kernel code and data, maybe
memory backing kernel malloc())

One possiblity would be to leave the system using 4/8k pages, but avoid
generating the 2nd (3rd?) level page tables until you fault on the higher
one.  The system can then decide whether to map 1Mb of contiguous memory
for the superpage, or allocate the lower page table and a single entry.

All rather complex!

    David