[Spice-devel] SPICE Fedora 15 guest X running at 100%

Thu Jun 16 15:16:33 PDT 2011

On Thu, 2011-06-16 at 23:00 +0100, --[ UxBoD ]-- wrote:
> ----- Original Message -----
> > On Thu, 2011-06-16 at 11:26 -0400, Marian Krcmarik wrote:
> > > 
> > > ----- Original Message -----
> > > > From: "John A. Sullivan III" <jsullivan at opensourcedevel.com>
> > > > To: "Alon Levy" <alevy at redhat.com>
> > > > Cc: spice-devel at lists.freedesktop.org
> > > > Sent: Wednesday, June 15, 2011 11:54:17 PM
> > > > Subject: Re: [Spice-devel] SPICE Fedora 15 guest X running at
> > > > 100%
> > > > On Thu, 2011-06-16 at 01:41 +0200, Alon Levy wrote:
> > > > > On Wed, Jun 15, 2011 at 04:58:21PM -0400, John A. Sullivan III
> > > > > wrote:
> > > > > > On Wed, 2011-06-15 at 16:08 -0400, John A. Sullivan III
> > > > > > wrote:
> > > > > <snip>>
> > > > > > I checked my Xorg.0.log file and noticed that I was getting
> > > > > > persistent
> > > > > > messages about cache failures and out of memory. It looks
> > > > > > like the
> > > > > > vram
> > > > > > parameter was set to something like 9216.
> > > > > >
> > > > > > So I changed it to 256000. To my surprise, the SPICE client
> > > > > > connected
> > > > > > but I had no mouse and no keyboard. I stopped the VM and
> > > > > > redefined
> > > > > > it
> > > > > > with 128000 and I now had keyboard and video but still had
> > > > > > the
> > > > > > same
> > > > > > excessive X utilization - John
> > > > >
> > > > > hmm.. yes, this is a well known problem - I thought libvirt
> > > > > fixed
> > > > > it. What
> > > > > version of libvirt are you using? The default memory is 64MB
> > > > > btw.
> > > > 
> > > > 0.8.8-4.fc15 Thanks - John
> > > 
> > > Try newer libvirt. Changing attribute vram in element model (i.e.
> > > <model type='qxl' vram='65536' heads='1'/>) seems to have no
> > > impact on qemu instance when I use 0.8.8-4 libvirt. When I use
> > > libvirt-0.9.2-1 I can see that option -global qxl-vga.vram_size is
> > > passed to qemu.
> > <snip>
> > It has been an interesting afternoon working on this one.  We dumped
> > the
> > libvirt configuration with domxml-to-native.  The original
> > configuration
> > translates into:
> > 
> > LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin
> > QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -S -M pc-0.14 -enable-kvm -m
> > 2048
> > -smp 2,sockets=2,cores=1,threads=1 -name lindesk01.pacifera.com -uuid
> > 6beff77b-efef-41ab-5e3f-0206c94a3e84 -nodefconfig -nodefaults
> > -chardev
> > socket,id=charmonitor,path=/var/lib/libvirt/qemu/lindesk01.pacifera.com.monitor,server,nowait
> > -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc
> > -boot c -device
> > virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
> > file=/dev/mapper/ilindesk01,if=none,id=drive-virtio-disk0,boot=on,format=raw
> > -device
> > virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0
> > -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw
> > -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0
> > -netdev tap,script=/etc/qemu/br0/qemu-ifup,id=hostnet0 -device
> > rtl8139,netdev=hostnet0,id=net0,mac=00:00:00:00:00:00 -chardev
> > pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0
> > -chardev spicevmc,id=charchannel0,name=vdagent -device
> > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
> > -usb -device usb-tablet,id=input0 -spice
> > port=5700,addr=0.0.0.0,disable-ticketing -vga qxl -device
> > intel-hda,i
> >  d=sound0,bus=pci.0,addr=0x4 -device
> >  hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
> >  virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
> > 
> > I then edited it by removing the -S, a couple of the early parameters
> > like uuid and nodefconfig and added -global qxl-vga.vram_size=131072.
> > The new command line was:
> > 
> > QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -M pc-0.14 -enable-kvm -m 2048
> > -smp 2,sockets=2,cores=1,threads=1 -name lindesk01.pacifera.com
> > -device
> > virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive
> > file=/dev/mapper/ilindesk01,if=none,id=drive-virtio-disk0,boot=on,format=raw
> > -device
> > virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0
> > -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw
> > -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0
> > -netdev tap,script=/etc/qemu/br0/qemu-ifup,id=hostnet0 -device
> > rtl8139,netdev=hostnet0,id=net0,mac=00:00:00:00:00:00 -chardev
> > pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0
> > -chardev spicevmc,id=charchannel0,name=vdagent -device
> > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
> > -usb -device usb-tablet,id=input0 -spice
> > port=5700,addr=0.0.0.0,disable-ticketing -vga qxl -global
> > qxl-vga.vram_size=131072 -device
> > intel-hda,id=sound0,bus=pci.0,addr=0x4 -device
> > hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
> > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
> > 
> > The result was much better.  Still slower than Windows it seemed and
> > X
> > still ran hot but not impossibly hot.
> > 
> > I then wanted to see if the only difference was adding the vga.ram
> > parameter so I added it to the old command line (and stripped the
> > -S).
> > Performance seemed somewhere in between.  X was running a little
> > hotter
> > but it was still usable though slow.  I then wondered if it was just
> > KDE4 bloat, e.g., when I click on Klipper, I get a corrupted block of
> > screen until it sorts out a second or two later.  So I exited KDE4
> > and
> > started twm.  To my great surprise, X shot to 100%.
> > 
> > I then rebooted into the earlier modified, better behaving command
> > line
> > and started twm.  Lo and behold, 100% CPU on X again.
> > 
> > I'm not sure what that means but I thought I'd pass it along.  I'll
> > let
> > you know what else I find.  Thanks - John
> > 
> 
> From what I was told before it is due to the whole image being passed back through the X driver.

Yes but it is interesting that we were able to go from unusable to quite
usable except for twm.  And that, as reported, libvirt 0.8.8 is not
passing the vram parameter.  Thanks - John