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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
