Date: Thu, 15 Mar 2012 18:40:22 -0500 From: Alan Cox <alc@rice.edu> To: Nathan Whitehorn <nwhitehorn@freebsd.org> 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: <4F627DE6.1000602@rice.edu> In-Reply-To: <4F62737C.7060100@freebsd.org> References: <201203151936.q2FJaqTr080483@svn.freebsd.org> <4F626AB8.3090509@rice.edu> <4F62737C.7060100@freebsd.org>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F627DE6.1000602>