Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Nov 2006 13:00:18 -0600
From:      Alan Cox <alc@cs.rice.edu>
To:        Kip Macy <kip.macy@gmail.com>,  arch@freebsd.org
Cc:        Alan Cox <alc@cs.rice.edu>
Subject:   Re: superpage plans
Message-ID:  <45649E42.70409@cs.rice.edu>
In-Reply-To: <b1fa29170611220939g32469638ncf3a3ddd4bba3670@mail.gmail.com>
References:  <b1fa29170611220939g32469638ncf3a3ddd4bba3670@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Kip Macy wrote:

> Do you have any thoughts on when superpage support might go into -CURRENT?
>
I plan to do it over the Christmas holidays.  I will merge it in three 
stages: First, the new buddy-style physical memory allocator 
(vm/vm_phys.c).  Second, the superpage reservation system.  Third, pmap 
support for individual architectures.

Aside from the direct benefits of superpage support on TLB performance 
for applications, there are also some other side benefits: First, in the 
pmap for amd64, arm, and i386, we maintain a single pv list per 
superpage.  So, substantial memory savings are possible for applications 
that share large amounts of memory between address spaces.  Second, the 
new physical memory allocator tries to cluster allocations in the 
physical address space.  This is beneficial on architectures like amd64 
where we extensively use the kernel's direct map to access kernel data 
because we experience fewer TLB misses.  Third, contigmalloc(9) is 
completely reimplemented.  So, for example, M_NOWAIT actually has an 
effect.  In particular, Giant is no longer required for M_NOWAIT 
allocations.  Fourth, the new physical memory allocator supports sparse 
physical address spaces, like the Itaniums have.  At present, -CURRENT 
cannot utilize the entire physical memory on many Itaniums.

There is only one caveat.  Idle-time page prezeroing is not supported.  
However, ever since the VM system emerged from the Giant kernel lock, 
I've seen little or no benefit from it.  In any case, I've left the 
inferfaces in place so it could return if an effective implementation is 
found.

Lastly, page coloring dies.  However, the beneficial effects of page 
coloring are for the most part captured by superpages.  Specifically, 
regardless of whether the pmap is able to promote a particular region of 
the address space to a superpage, e.g., due to heterogenous access 
rights of pages within the region, if the memory has been provided by 
the reservation system it will have "perfect" coloring.

Regards,
Alan




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45649E42.70409>