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/
Home Products Support Community News


Re: [Xen-devel] [PATCH][HVM] remove qemu shadow_vram patch forperformanc

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][HVM] remove qemu shadow_vram patch forperformance
From: "Christian Limpach" <christian.limpach@xxxxxxxxx>
Date: Thu, 22 Mar 2007 23:40:12 +0000
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, "Li, Xin B" <xin.b.li@xxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Delivery-date: Thu, 22 Mar 2007 16:39:05 -0700
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gxMSauWEl/grRvaxOLuhSFNr1cDDCcN0PyrDOaqs+nGGacLa2srIH6OYCH0G2gYUczvQKLKXCE9F33ZyvmoneMtMFBNPkHt8DoU+vmkzf89cSd6M3clvRiKleMD3dF+BV8dAKpb5CuJy24d168tonWQe/LeUCLhQ3EhqQqg5Ijg=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hCnncrIHQTqWqU0mtZ7jtHkV8VnqvB1x2l4LgSrp96ZkEKkTpLu2oQh4deajUD6V1Br22jgJMrTHcPCLzVhbZMxgvUZ/hTFizBcKS3ZVUounBztNvw9hHz10FVOTy2gc4ymVQNMAAnpOJtoPljAAq17vv41ojyyBEPXvxmbwOOQ=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2255034.4A25%Keir.Fraser@xxxxxxxxxxxx>
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: <B30DA1341B0CFA4893EF8A36B40B5C5DE9DD37@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C2255034.4A25%Keir.Fraser@xxxxxxxxxxxx>
Reply-to: Christian.Limpach@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 3/20/07, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
I punted on this one. :-) Christian wasn't sure about it either, hence it's
not been checked in.

My main concern is that with the patch we will be doing the transform
from vga ram into the display memory everytime (vga_draw_line, some
versions are quite expensive) and I don't see how that could be faster
than doing the sse2 optimized compare and copy?

When you test this, are the displays active or not, i.e. is the
display changing a lot or are they at the screen saver?

Maybe if the SDL frontend notices that its window is obscured, it
should tell the rest of the code that a scan is not required...

Same for VNC...


 -- 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 mailing list