[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.