From owner-cvs-src@FreeBSD.ORG Sun Jun 10 04:35:35 2007 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E53E16A421; Sun, 10 Jun 2007 04:35:35 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id CB14413C43E; Sun, 10 Jun 2007 04:35:34 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l5A4ZWbo001026 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 10 Jun 2007 00:35:33 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sat, 9 Jun 2007 21:35:05 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Alan Cox In-Reply-To: <200706100049.l5A0nH16004198@repoman.freebsd.org> Message-ID: <20070609213443.B60816@10.0.0.1> References: <200706100049.l5A0nH16004198@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 04:35:35 -0000 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) >