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
_______________________________________________
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"
