| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Why is 'emulate' as good as writable PT's?
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home