[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] qemu-dm performance
Since I wrote the code all I can do is say that Anthony is completely correct, there's a shadow frame buffer that `vram_dirty' compares to see if the HVM guest has modified it's frame buffer. Deleting this function should result in a blank VGA screen for your HVM guest, I'm really curious how you got this to work. Are you accessing the guest from the serial line rather than the VGA console? -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Donald.D.Dugger@xxxxxxxxx Ph: (303)443-3786 >-----Original Message----- >From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx >[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of >Anthony Liguori >Sent: Wednesday, September 20, 2006 2:13 PM >To: Tommie McAfee >Cc: xen-devel@xxxxxxxxxxxxxxxxxxx >Subject: Re: [Xen-devel] qemu-dm performance > >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@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@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |