svn commit: r233011 - head/sys/powerpc/aim

[Alan Cox]

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