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
|
Home