From owner-cvs-all@FreeBSD.ORG Sun Jun 10 00:49:17 2007 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACB8E16A400; Sun, 10 Jun 2007 00:49:17 +0000 (UTC) (envelope-from alc@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [69.147.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 9F04713C44C; Sun, 10 Jun 2007 00:49:17 +0000 (UTC) (envelope-from alc@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.8/8.13.8) with ESMTP id l5A0nHWK004210; Sun, 10 Jun 2007 00:49:17 GMT (envelope-from alc@repoman.freebsd.org) Received: (from alc@localhost) by repoman.freebsd.org (8.13.8/8.13.8/Submit) id l5A0nH16004198; Sun, 10 Jun 2007 00:49:17 GMT (envelope-from alc) Message-Id: <200706100049.l5A0nH16004198@repoman.freebsd.org> From: Alan Cox Date: Sun, 10 Jun 2007 00:49:16 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/sys/vm vm_phys.c vm_phys.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 00:49:17 -0000 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. 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)