>-----Original Message-----
>From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
>Sent: 2008年1月23日 17:52
>To: Xin, Xiaohui
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel][PATCH]Provide 3 times continously writes check and
>unshadow the guest page
>
>Hi,
>
>At 13:41 +0800 on 23 Jan (1201095692), Xin, Xiaohui wrote:
>> The patch checks if the guest continuously writes 3 times to the same
>> guest page table pages, if yes, then unshadow the guest pages.
>
>Interesting. I would expect this to be painful on 64-bit windows, which
>writes more intermediate values to pagetables, but the numbers disagree.
>Maybe it never writes three values back to back. Certainly a better way
>of detecting when pagetables are reused as data pages is welcome, though
>we've been bitten here before.
>
>> The idea is copied from the KVM side. And since the idea has
>> overlapped with the now optimization in the now Xen shadow code, so
>> the patch removes the optimization part which when the guest writes 2
>> continuously 0 to the same page, then unshadow the guest page.
>
>So to summarize, seven of your performance tests get slightly worse, two
>get slightly better and two (x64 linux kernel build times and iperf) get
>markedly better. Do you have confidence intervals for the measurements,
>by the way?
>
Yes, we have confidence with the measurements, since it's always the average
number of 5 or 6 times.
>Do your HVM linux guests have PV drivers? If not, does using PV drivers
>make a difference to iperf?
>
No, the guests we used do not have PV drivers. What your concerns are on this
point?
>> + if ( v->arch.paging.shadow.last_emulated_gfn ==
>> + mfn_to_gfn(v->domain, gmfn) )
>
>Is there a reason for tracking this a a GFN instead of an MFN?
>
You're right, guest gfn always have one gmfn, so we have over-thought on it.
Then, how about your final opinion about the patch? We did not see it clearly
from your reply. :-(
>Cheers,
>
>Tim.
>
>--
>Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>Principal Software Engineer, Citrix Systems (R&D) Ltd.
>[Company #02300071, SL9 0DZ, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|