RE: [Xen-devel] [PATCH][HVM] remove qemu shadow_vram patch forperformance

["Li, Xin B" <xin.b.li@xxxxxxxxx>]

Keir, do you think this patch is OK?
-Xin 

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Zhai, Edwin
>Sent: Friday, March 16, 2007 11:04 AM
>To: Keir Fraser
>Cc: Ian Pratt; xen-devel@xxxxxxxxxxxxxxxxxxx; Zhai, Edwin
>Subject: Re: [Xen-devel] [PATCH][HVM] remove qemu shadow_vram 
>patch forperformance
>
>On Thu, Mar 15, 2007 at 10:50:13AM +0000, Keir Fraser wrote:
>> 
>> 
>> 
>> On 15/3/07 03:30, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> wrote:
>> 
>> > remove qemu shadow_vram patch and force a whole screen 
>update each time for
>> > performance.
>> > 
>> > W/O this patch, there is huge performance drop in HVM 
>domain when adding other
>> > guest(windows or linux with xwindow).
>> > 
>> > shadow_vram_revert.patch - revert the shadow_vram patch
>> > shadow_vram_force_update.patch - explictly redraw screen each time
>> 
>> How can updating the whole screen 30 times a second be 
>faster than the
>> memcmp() that we do currently?
>
>as far as i can tell, the bottle neck is that orig method does 
>memcmp and memcpy 
>byte by byte. furthermore, orig method can void a update by 
>multiple memcmp only 
>if all bytes are equal, which is in the minority.
>
>there is no doubt we need a vram dirty for qemu, but current 
>one is not the 
>best. we can make a new one in future by shadow or something else.
>
>thanks,
>
>> 
>>  -- Keir
>> 
>
>-- 
>best rgds,
>edwin
>
>_______________________________________________
>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