WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Re: [PATCH][RFC]Provide fast write emulation path torele

To: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH][RFC]Provide fast write emulation path torelease shadow lock
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 25 Jan 2008 09:54:27 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 24 Jan 2008 17:56:20 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <FF386CB4AE0E4648B0A96060EC00F36C7263AF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <D470B4E54465E3469E2ABBC5AFAC390F024D8E8C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080122092608.GA12891@xxxxxxxxxxxxxxxxxxxxx> <FF386CB4AE0E4648B0A96060EC00F36C7263AF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Achc2W6lkubPm+D0QWGysocInGUBLACGKs1gAAC0eCA=
Thread-topic: [Xen-devel] Re: [PATCH][RFC]Provide fast write emulation path torelease shadow lock
So Tim, can you help see whether our test approach is 
wrong or it's the fact with existing today's code? Or you 
may suggest some scenarios you're sure working with 
latest logic and then we can reproduce as comparison...

Thanks,
Kevin

>From: Xu, Dongxiao 
>Sent: 2008年1月25日 9:41
>
>Hi, Tim and Kevin,
>    I did some stability test with and without Kevin's patch: 
>
>First guest (Linux):  kernel build;
>Second guest (Linux): network copy;
>Third guest (Windows): Sysmark 2007;
>
>In dom0, I did local migration to the three guest.
>
>But I found that even without Kevin's patch, the guest would 
>be blue screen in Windows or print some call trace in Linux 
>guest. Have you seen this issue before? Thanks!
>
>Best Regards,
>Xu Dongxiao
>
>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Tim Deegan
>Sent: 2008年1月22日 17:26
>To: Tian, Kevin
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: [Xen-devel] Re: [PATCH][RFC]Provide fast write 
>emulation path torelease shadow lock
>
>At 10:20 +0800 on 22 Jan (1200997253), Tian, Kevin wrote:
>> We also did series of tests on 32/32pae/32e: (host is 32e)
>>                    32       32pae       32e
>> ----Linux----
>> kernel build   +1%    +0.86%    +1.9%
>> Specjbb        +0.9% +1.61%    +0.32%
>> 
>> ----XP----
>> Sysbench     N/A     -0.05%     -0.32%(*)
>> 
>> * Sysbench score is not very stable on 32e guest, with up
>> to 6% variation observed in 5 rounds running. 32pae is
>> stable. 32 XP image was unfortunately corrupted at test 
>> cycle, so not test yet. Don't want to hold here from getting
>> early comments. :-)
>> 
>> I thought the performance gain should be straightforward
>> with this patch, and thus would like to know comment
>> like:
>>      - Is it a right direction?
>
>Looks good to me! 
>
>>      - Is there anything wrong or missed in patch?
>
>Nothing fundamental that I can see by reading through it.  One 
>thing I'd
>change is to avoid introducing "vfn": a virtual address >> PAGE_SIZE is
>just a "page number".
>
>>      - Any more benchmarks should we test?
>
>Anything and everything. :)  Specially multi-vcpu mixed operations
>(e.g. kernel compile + ltp + network traffic) while doing live migrate.
>Even when they look as clean as this one, changes in the shadow fault
>handler tend to chase out implicit/forgotten assumptions.
>
>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
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel