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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F627DE6.1000602>