Date: Thu, 15 Mar 2012 19:12:38 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Alan Cox <alc@rice.edu> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233011 - head/sys/powerpc/aim Message-ID: <4F628576.6010802@freebsd.org> In-Reply-To: <4F627DE6.1000602@rice.edu> References: <201203151936.q2FJaqTr080483@svn.freebsd.org> <4F626AB8.3090509@rice.edu> <4F62737C.7060100@freebsd.org> <4F627DE6.1000602@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F628576.6010802>