cvs commit: src/sys/vm vm_phys.c vm_phys.h

[Jeff Roberson]

On Sun, 10 Jun 2007, Alan Cox wrote:

> alc         2007-06-10 00:49:16 UTC
>
>  FreeBSD src repository
>
>  Added files:
>    sys/vm               vm_phys.c vm_phys.h
>  Log:
>  Add a new physical memory allocator.  However, do not yet connect it
>  to the build.

Can you tell us about the time complexity of allocating multiple 
physically contiguous pages?

Thanks,
Jeff

>
>  This allocator uses a binary buddy system with a twist.  First and
>  foremost, this allocator is required to support the implementation of
>  superpages.  As a side effect, it enables a more robust implementation
>  of contigmalloc(9).  Moreover, this reimplementation of
>  contigmalloc(9) eliminates the acquisition of Giant by
>  contigmalloc(..., M_NOWAIT, ...).
>
>  The twist is that this allocator tries to reduce the number of TLB
>  misses incurred by accesses through a direct map to small, UMA-managed
>  objects and page table pages.  Roughly speaking, the physical pages
>  that are allocated for such purposes are clustered together in the
>  physical address space.  The performance benefits vary.  In the most
>  extreme case, a uniprocessor kernel running on an Opteron, I measured
>  an 18% reduction in system time during a buildworld.
>
>  This allocator does not implement page coloring.  The reason is that
>  superpages have much the same effect.  The contiguous physical memory
>  allocation necessary for a superpage is inherently colored.
>
>  Finally, the one caveat is that this allocator does not effectively
>  support prezeroed pages.  I hope this is temporary.  On i386, this is
>  a slight pessimization.  However, on amd64, the beneficial effects of
>  the direct-map optimization outweigh the ill effects.  I speculate
>  that this is true in general of machines with a direct map.
>
>  Approved by:    re
>
>  Revision  Changes    Path
>  1.1       +689 -0    src/sys/vm/vm_phys.c (new)
>  1.1       +52 -0     src/sys/vm/vm_phys.h (new)
>