Re: RFC: two-level page tables for 16KB pages on LP64 kernels

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Aug 28, 2011 at 02:33:51PM -0700, Matt Thomas wrote:
> 
> On Aug 28, 2011, at 2:32 PM, Manuel Bouyer wrote:
> 
> > On Fri, Aug 26, 2011 at 03:35:13PM -0700, Matt Thomas wrote:
> >> 
> >> Normally, MIPS uses a 3 level page table for a 64-bit kernel which gives 
> >> 1TB (40 [12+10+9+9] bits) of user address space when using 4KB pages.  A 3 
> >> level page table using 16KB pages can address 256TB (48 [14+12+11+11] 
> >> bits) while a 2 level page table using 16KB pages can address 128GB (37 
> >> [14+12+11] bits) of address space.
> >> 
> >> Thinking about it, 128GB seems to more than enough on the GDIUM or other 
> >> Loongson2 base platforms but it is significantly less the 16TB that it 
> >> could use.  I have to think the smaller (but adequate) address space using 
> >> a simple 2 level page table might result in a small performance boost.
> >> 
> >> I figure this could be a config file option.  Maybe even defining 
> >> VM_MAX_USER_ADDRESS in an option file and letting the kernel figure out 
> >> how many levels are needed to accomodate that maximum.
> > 
> > 
> > How many instructions will it save in the trap handler ?
> > With 16k pages we should already have less TLB miss; I'm not sure the
> > performance gain justifies the maintenance cost of having another TLB
> > handler ...
> > but if you have patches to test, I'd be happy to try and benchmark on
> > my fuloong.
> 
> It will also save 1 16KB page per process (pmap).

That's little gain on a system that can take 1Gb of RAM, but maybe you
have in mind some embeded systems that could also benefit from this ?

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--