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] qemu-dm performance

To: Tommie McAfee <tommie.mcafee@xxxxxxxxxx>
Subject: Re: [Xen-devel] qemu-dm performance
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Wed, 20 Sep 2006 15:12:46 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 20 Sep 2006 13:13:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1158782504.4960.142.camel@mah-chine>
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: <1158782504.4960.142.camel@mah-chine>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060728)
There was a long thread about this topic already plus a patch floating around. I don't think vram_dirty is the problem.

vram_dirty seems to be Xen-specific. Presumably, since we map the framebuffer directly into the guest, we cannot use write-faulting anymore to track dirtying. Instead, it looks like we rely on a double buffer to determine which portions of the screen change.


Anthony Liguori

Tommie McAfee wrote:
I've been investigating why qemu-dm is causing %CPU to be high when
viewing fully vitalized guests with vncviewer( about 20% usage ).
I've looked at the code, and one area that I'm curious about is the
vram_dirty() function in tools/ioemu/hw/vga.c.  Please correct me if I'm
wrong, but vram_dirty() seems to be using SSE inline functions to
optimize it's bit-shifting/masking/loading/storing/comparison operations
to see if dirty bits need to be set for a page within the shadow table.
Also, I used gdb to make sure that I'm really executing the SSE
optimized version of vram_dirty() that utilizes xmm0 registers.

So out of curiosity, I decided to comment out calls to vram_dirty() from
vga_draw_graphic() and the guests still behave normally, but CPU% now
drops to 8%.  I know this is silly, and that I should expect a CPU drop
for commenting out code, but why is vram_dirty() adding 12% CPU
utilization when it can be commented out without crashing my viewer, and
without me even noticing a difference in the guests behavior?  Can
someone help me to understand the purpose vram_dirty serves and perhaps
why it seems 2 be so CPU intensive without really changing the way my
virtual guest behaves?

Also, where else should I look in the code for possible explanations to
why qemu-dm uses 20% CPU simply to view a guest.  All comments and
suggestions regarding this matter are appreciated,


T. McAfee
Xen Testing

Xen-devel mailing list

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>