From owner-svn-src-all@FreeBSD.ORG Fri Mar 16 14:56:05 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A143106566B; Fri, 16 Mar 2012 14:56:05 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by mx1.freebsd.org (Postfix) with ESMTP id 062C38FC15; Fri, 16 Mar 2012 14:56:04 +0000 (UTC) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id CBEDD291FE6; Fri, 16 Mar 2012 09:48:52 -0500 (CDT) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id BB55E297607; Fri, 16 Mar 2012 09:48:52 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh2.mail.rice.edu, auth channel Received: from mh2.mail.rice.edu ([127.0.0.1]) by mh2.mail.rice.edu (mh2.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id GGXLocJ5e8YG; Fri, 16 Mar 2012 09:48:52 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 2987B292030; Fri, 16 Mar 2012 09:48:52 -0500 (CDT) Message-ID: <4F6352D3.10005@rice.edu> Date: Fri, 16 Mar 2012 09:48:51 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Nathan Whitehorn References: <201203151936.q2FJaqTr080483@svn.freebsd.org> <4F626AB8.3090509@rice.edu> <4F62737C.7060100@freebsd.org> <4F627DE6.1000602@rice.edu> <4F628576.6010802@freebsd.org> In-Reply-To: <4F628576.6010802@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 14:56:05 -0000 On 03/15/2012 19:12, Nathan Whitehorn wrote: > 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()? > Hmm. I hadn't looked at this man page before. It's rather misleading. pmap_copy() doesn't copy physical pages. It copies page table entries. It is used by fork() to pre-populate the page table, so that soft faults don't occur in the child process. If you perform execve() immediately after fork(), then, yes, pmap_copy() may just slow things down. > - pmap_object_init_pt() > This one looks an important potential optimization. > This is only used to avoid soft faults on device mappings. > - 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? The short answer is no. With the limitations of the AIM MMU, you can really only support superpages under a user/kernel interface like Solaris ISM, e.g., flags to SysV shm or shm_open(). Alan