[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-discuss] [Qemu-devel] Cross-posted : Odd QXL/KVM performance i
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-discuss] [Qemu-devel] Cross-posted : Odd QXL/KVM performance issue with a Windows 7 Guest |
Date: |
Mon, 9 Sep 2019 16:22:05 +0100 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
* Brad Campbell (address@hidden) wrote:
>
> On 7/9/19 03:03, Dr. David Alan Gilbert wrote:
> > * Brad Campbell (address@hidden) wrote:
> > > On 2/9/19 6:23 pm, Brad Campbell wrote:
> > >
> > > > Here is the holdup :
> > > >
> > > > 11725@1567416625.003504:qxl_ring_command_check 0 native
> > > > 11725@1567416625.102653:qxl_io_write 0 native addr=0 (QXL_IO_NOTIFY_CMD)
> > > > val=0 size=1 async=0
> > > >
> > > > ~100ms delay prior to each logged QXL_IO_NOTIFY_CMD on the AMD box which
> > > > explains the performance difference. Now I just need to figure out if
> > > > that lies in the guest, the guest QXL driver, QEMU or SPICE and why it
> > > > exhibits on the AMD box and not the i7.
> > > >
> > > > To get to this point, I recompiled the kernel on the i7 box with both
> > > > AMD and Intel KVM modules. Once that was running I cloned the drive and
> > > > put it in the AMD box, so the OS, software stack and all dependencies
> > > > are identical.
> > > Reacp :
> > >
> > > I have a machine with a Windows 7 VM which is running on an i7-3770. This
> > > works perfectly.
> > >
> > > Clone the disk and put it in a new(ish) AMD Ryzen 1500x machine and the
> > > display output using qxl/spice is now limited to ~5-7fps.
> > >
> > > I originally cloned the entire machine to keep the software versions
> > > identical.
> > >
> > > To simplify debugging and reproduction I'm now using :
> > > - An identical SPICE version to that on the i7.
> > > - A fresh 64 bit Windows 7 VM.
> > > - The D2D benchmark from Crystalmark 2004R7.
> > >
> > > The machine is booted with :
> > >
> > > qemu -enable-kvm \
> > > -m 8192\
> > > -rtc base=localtime\
> > > -vga qxl\
> > > -device qxl\
> > > -global qxl-vga.guestdebug=3\
> > > -global qxl-vga.cmdlog=1\
> > > -global qxl-vga.vram_size=65536\
> > > -global qxl.vram_size=65536\
> > > -global qxl-vga.ram_size=65536\
> > > -global qxl.ram_size=65536\
> > > -net nic,model=virtio\
> > > -net tap,ifname=tap0,script=/etc/qemu-ifup,vhost=on\
> > > -usbdevice tablet\
> > > -spice port=5930,disable-ticketing\
> > > -device virtio-serial\
> > > -chardev spicevmc,id=vdagent,name=vdagent\
> > > -device virtserialport,chardev=vdagent,name=com.redhat.spice.0\
> > > -smp 3,maxcpus=3,cores=3,threads=1,sockets=1\
> > > -cpu qemu64,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \
> > -cpu qemu64 is almost always a bad idea; does -cpu host help ?
> >
> > Dave
>
>
> No. I was using -cpu host. I changed it to qemu64 for testing so I could add
> & remove -enable-kvm for testing without the machine changing drivers about.
Oh, hmm.
Sorry I don't know too much where to look then; you have any of:
a) Windows
b) guest graphics drivers
c) spice server in qemu
and probalby some more.
So I think it's going to be a case of profiling on the two different
systems and see if you can spot anything in particular that stands out.
Dave
> Regards,
>
> Brad
>
> --
> An expert is a person who has found out by his own painful
> experience all the mistakes that one can make in a very
> narrow field. - Niels Bohr
>
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK