[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Keir, do you think this patch is OK?

>-----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.
>>  -- Keir
>best rgds,
>Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.