Re: Why is 'emulate' as good as writable PT's?

[Andrew Theurer <habanero@us.ibm.com>]

Ian Pratt wrote:
>> Could there be situations were we are inadvertently triggering a
>> writable page table, where we should just be doing a
>>     
> update_va_mapping()?
>
> Almost certainly. Singleton (or small batch) updates should not be using
> writeable pagetables, and should use update_va_mapping (or mmu_update if
> the VA isn't known or may not be mapped).
>
> ~18 months ago Rolf wrote and checked in profile code to collect a
> histogram of the number of entries found to be modified when writeable
> pagetables are flushed.
> At the time there was a big spike at '1' which was fixed, but with all
> the various linux version upgrades it likely needs revisiting. 
>
> The profile code also records the EIP that caused the writeable
> pagetables operation, so if you print out the value a few times you'll
> quickly find the culprit.
>
> Thanks,
> Ian
>   
Yes, we definitely have a problem here.  Tons of flushes with 
modified=1, and lots with <=10.  The three benchmarks all seem to hit 
the same areas.  Here is the output from running SDET, with snippets 
from System.map mixed in:

Out of a total of 19601 writable PT updates:

c01522b0 <=1   40    <=10    0       <=50    0       <=100    0      <=512    0
--------
c0151e90 T sys_mprotect
c01524d3 t .text.lock.mprotect


c014ed77 <=1 3418    <=10 4853       <=50 1674       <=100   70      <=512    0
--------
c014e84e T copy_page_range
c014efc6 T free_pgtables


c01522ab <=1 3728    <=10    0       <=50    0       <=100    0      <=512    0
--------
c0151e90 T sys_mprotect
c01524d3 t .text.lock.mprotect


c014b809 <=1 3752    <=10 1654       <=50  302       <=100   10      <=512    3
--------
c014b300 T unmap_vmas
c014b9ba T zap_page_range


c014b80b <=1   32    <=10   30       <=50   30       <=100    1      <=512    0
--------
c014b300 T unmap_vmas
c014b9ba T zap_page_range


-Andrew