From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: qemu-dm performance Date: Wed, 20 Sep 2006 15:12:46 -0500 Message-ID: <4511A0BE.7030701@us.ibm.com> References: <1158782504.4960.142.camel@mah-chine> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1158782504.4960.142.camel@mah-chine> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tommie McAfee Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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. Regards, 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, > > thx, > > T. McAfee > Xen Testing > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >