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>