superpage plans
Alan Cox
alc at cs.rice.edu
Wed Nov 22 11:00:33 PST 2006
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
More information about the freebsd-arch
mailing list