From owner-freebsd-arch@FreeBSD.ORG Wed Nov 22 19:00:33 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DC4716A4FB for ; Wed, 22 Nov 2006 19:00:33 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB67A43D62 for ; Wed, 22 Nov 2006 18:59:50 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 114812C2ADC; Wed, 22 Nov 2006 13:00:20 -0600 (CST) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RC5B1tk3wHvm; Wed, 22 Nov 2006 13:00:19 -0600 (CST) Received: from [216.63.78.18] (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 4602B2C2AD1; Wed, 22 Nov 2006 13:00:19 -0600 (CST) Message-ID: <45649E42.70409@cs.rice.edu> Date: Wed, 22 Nov 2006 13:00:18 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050817 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kip Macy , arch@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox Subject: Re: superpage plans X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2006 19:00:33 -0000 Kip Macy wrote: > Do you have any thoughts on when superpage support might go into -CURRENT? > I plan to do it over the Christmas holidays. I will merge it in three stages: First, the new buddy-style physical memory allocator (vm/vm_phys.c). Second, the superpage reservation system. Third, pmap support for individual architectures. Aside from the direct benefits of superpage support on TLB performance for applications, there are also some other side benefits: First, in the pmap for amd64, arm, and i386, we maintain a single pv list per superpage. So, substantial memory savings are possible for applications that share large amounts of memory between address spaces. Second, the new physical memory allocator tries to cluster allocations in the physical address space. This is beneficial on architectures like amd64 where we extensively use the kernel's direct map to access kernel data because we experience fewer TLB misses. Third, contigmalloc(9) is completely reimplemented. So, for example, M_NOWAIT actually has an effect. In particular, Giant is no longer required for M_NOWAIT allocations. Fourth, the new physical memory allocator supports sparse physical address spaces, like the Itaniums have. At present, -CURRENT cannot utilize the entire physical memory on many Itaniums. There is only one caveat. Idle-time page prezeroing is not supported. However, ever since the VM system emerged from the Giant kernel lock, I've seen little or no benefit from it. In any case, I've left the inferfaces in place so it could return if an effective implementation is found. Lastly, page coloring dies. However, the beneficial effects of page coloring are for the most part captured by superpages. Specifically, regardless of whether the pmap is able to promote a particular region of the address space to a superpage, e.g., due to heterogenous access rights of pages within the region, if the memory has been provided by the reservation system it will have "perfect" coloring. Regards, Alan