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 patchforperformance

To: <Christian.Limpach@xxxxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH][HVM] remove qemu shadow_vram patchforperformance
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Fri, 23 Mar 2007 08:38:39 +0800
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 17:37:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <3d8eece20703221640j57cf77b3hfc5dfe0d32846ce5@xxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acds2333bOc+hnKYSZC3V/baQPPbhAAAUT5w
Thread-topic: [Xen-devel] [PATCH][HVM] remove qemu shadow_vram patchforperformance
Christian Limpach wrote:
> 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...
        It doesn't matter if the screen is changing contents or not.
Comparing shadow vram with vram already consumes 2X memory bus
cycle. In case of 8 VMs, we get 16X memory bus cycle (and a lot
of cache flush , page fault for shadow vram and flush of other TLBs).
 While w/o memcmp, we only got 1 full screen update.
        Given that in multi core environment, different processor
different Qemu Windows will compete the memory access. So it seems
very nature the compare approach will become a bottle neck when VM #
        BTW, We didn't see performance issue with single VM either, and
in multiple VM environment, most Qemu windows are usually hidden.

        thanks, eddie

Xen-devel mailing list