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

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

The major problem this patch is trying to fix is the performance drop
when multiple HVM guests are running, and I think we need a better
solution for this.
-Xin 

>-----Original Message-----
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
>Sent: Tuesday, March 20, 2007 4:48 PM
>To: Li, Xin B; Zhai, Edwin; Keir Fraser
>Cc: Ian Pratt; xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] [PATCH][HVM] remove qemu shadow_vram 
>patch forperformance
>
>I punted on this one. :-) Christian wasn't sure about it 
>either, hence it's
>not been checked in.
>
> -- Keir
>
>On 20/3/07 08:38, "Li, Xin B" <xin.b.li@xxxxxxxxx> wrote:
>
>> 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
>

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