Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Jun 2007 21:35:05 -0700 (PDT)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Alan Cox <alc@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/vm vm_phys.c vm_phys.h
Message-ID:  <20070609213443.B60816@10.0.0.1>
In-Reply-To: <200706100049.l5A0nH16004198@repoman.freebsd.org>
References:  <200706100049.l5A0nH16004198@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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)
>



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