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] [PATCH][HVM] remove qemu shadow_vram patch for performan

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][HVM] remove qemu shadow_vram patch for performance
From: "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Date: Fri, 16 Mar 2007 11:04:15 +0800
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Delivery-date: Thu, 15 Mar 2007 20:09:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C21ED565.B88C%keir@xxxxxxxxxxxxx>
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: <20070315033005.GD12238@xxxxxxxxxxxxxxxxxxxxxx> <C21ED565.B88C%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.11
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