From owner-svn-src-all@FreeBSD.ORG Fri Mar 16 00:12:40 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9718106564A; Fri, 16 Mar 2012 00:12:40 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 81ADB8FC0A; Fri, 16 Mar 2012 00:12:40 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0M0Y00I00B939300@smtpauth1.wiscmail.wisc.edu>; Thu, 15 Mar 2012 19:12:39 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.64.26]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0M0Y00211B92IF30@smtpauth1.wiscmail.wisc.edu>; Thu, 15 Mar 2012 19:12:39 -0500 (CDT) Date: Thu, 15 Mar 2012 19:12:38 -0500 From: Nathan Whitehorn In-reply-to: <4F627DE6.1000602@rice.edu> To: Alan Cox Message-id: <4F628576.6010802@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.64.26 X-Spam-PmxInfo: Server=avs-15, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.16.315, SenderIP=76.210.64.26 References: <201203151936.q2FJaqTr080483@svn.freebsd.org> <4F626AB8.3090509@rice.edu> <4F62737C.7060100@freebsd.org> <4F627DE6.1000602@rice.edu> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120311 Thunderbird/10.0.2 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233011 - head/sys/powerpc/aim X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 00:12:41 -0000 On 03/15/12 18:40, Alan Cox wrote: > On 3/15/2012 5:55 PM, Nathan Whitehorn wrote: >> On 03/15/12 17:18, Alan Cox wrote: >>> On 3/15/2012 2:36 PM, Nathan Whitehorn wrote: >>>> Author: nwhitehorn >>>> Date: Thu Mar 15 19:36:52 2012 >>>> New Revision: 233011 >>>> URL: http://svn.freebsd.org/changeset/base/233011 >>>> >>>> Log: >>>> Improve algorithm for deciding whether to loop through all >>>> process pages >>>> or look them up individually in pmap_remove() and apply the same >>>> logic >>>> in the other ranged operation (pmap_protect). This speeds up make >>>> installworld by a factor of 2 on powerpc64. >>>> >>>> MFC after: 1 week >>>> >>>> Modified: >>>> head/sys/powerpc/aim/mmu_oea64.c >>>> >>> >>> As an additional, related optimization, you should look into >>> implementing pmap_remove_pages(). >>> >>> Alan >>> >> >> Thanks! I didn't know about that one. Is there a reason it isn't >> called at the end of vm_pageout_map_deactivate_pages(), which seems >> to deactivate all pages with pmap_remove()? > > Yes, at least two reasons come to mind. Some implementations only > accept the caller's current pmap as an argument. Also, there > shouldn't be any other threads besides the caller using the pmap. > > OK, makes sense (though the PPC implementation doesn't have the needs-to-be-the-current-PMAP restriction). One more question while we're discussing this. I looked through the various PMAP functions, and found three more that aren't implemented: - pmap_copy() The man page for this one says "Actually implementing it may seriously reduce system performance." Is this true? Is there any point to implementing it if it would be no faster than repeatedly calling pmap_copy_page()? - pmap_object_init_pt() This one looks an important potential optimization. - pmap_align_superpage() PowerPC/AIM mostly only supports superpages in 256 MB regions, where all pages within that region must be superpages, and pages not in marked regions cannot be. Is there any way to usefully implement this in the context of our kernel superpage support? -Nathan