Date: Fri, 16 Mar 2012 09:48:51 -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: <4F6352D3.10005@rice.edu> In-Reply-To: <4F628576.6010802@freebsd.org> References: <201203151936.q2FJaqTr080483@svn.freebsd.org> <4F626AB8.3090509@rice.edu> <4F62737C.7060100@freebsd.org> <4F627DE6.1000602@rice.edu> <4F628576.6010802@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F6352D3.10005>