qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] vhost-scsi port to v1.1.0 + MSI-X performance regressio


From: Nicholas A. Bellinger
Subject: Re: [Qemu-devel] vhost-scsi port to v1.1.0 + MSI-X performance regression
Date: Tue, 24 Jul 2012 14:43:50 -0700

On Tue, 2012-07-24 at 13:20 -0700, Nicholas A. Bellinger wrote:
> On Tue, 2012-07-24 at 09:57 +0200, Jan Kiszka wrote:
> > On 2012-07-24 09:42, Nicholas A. Bellinger wrote:
> > > Hi Anthony, Stefan & QEMU folks,
> > > 
> 
> <SNIP>
> 
> > > However, thus far I've not been able to get virtio-scsi <-> tcm_vhost
> > > I/O to actually work against the latest qemu.git/master..  
> > > 
> > > So while doing a (manual) bisection w/ this series to track down the
> > > issue with qemu/master, I managed to run across something else..  With
> > > the vhost-scsi series applied, everything is working as expected up
> > > until the following commit:
> > > 
> > > commit 1523ed9e1d46b0b54540049d491475ccac7e6421
> > > Author: Jan Kiszka <address@hidden>
> > > Date:   Thu May 17 10:32:39 2012 -0300
> > > 
> > >     virtio/vhost: Add support for KVM in-kernel MSI injection
> > > 
> > > 
> > > This commit ends up triggering the following assert immediately after
> > > starting qemu with virtio-scsi <-> tcm_vhost:
> > > 
> > > qemu-system-x86_64: /usr/src/qemu.git/hw/msix.c:515:
> > >        msix_unset_vector_notifiers: Assertion 
> > > `dev->msix_vector_use_notifier &&
> > >                                     dev->msix_vector_release_notifier' 
> > > failed.
> > > 
> > > OK, so adding the following hack allows me to boot:

<SNIP>

> > Also, is there a git tree and a way to reproduce this without special
> > hardware needs?
> > 
> 
> I'll push this series + branches to demonstrate the issue into an public
> tree this afternoon.
> 

OK, the updated vhost-scsi QEMU working tree is now available here:

http://git.kernel.org/?p=virt/kvm/nab/qemu-kvm.git;a=summary

Please ignore the qemu-kvm.git name for the moment, as it really is
based on upstream qemu.  ;)

The branch breakdown looks like:

  master                401a663 remove unused QemuOpts parameter from net init 
functions
* vhost-scsi            bdd00bd msix: Add msix_nr_vectors_allocated
  vhost-scsi-merge      e4fdb8c [ahead 9] vhost-scsi: add -vhost-scsi host 
device
  vhost-scsi-workaround 32ed0db msix: Work-around for vhost-scsi with KVM 
in-kernel MSI injection

- 'vhost-scsi' contains vhost-scsi patches + pre commit 1523ed9e1d logic
   (Running stable at ~67.5K IOPs, see below)
- 'vhost-scsi-merge' contains a vhost-scsi series against yesterday's qemu.git 
HEAD
   (not working atm, but will be sending out for RFC shortly)
- 'vhost-scsi-workaround' contains the msix.c workaround to get commit 
1523ed9e1d to boot
   (reproducible performance regression, down to 6K IOPs)

> Also, the particular backend is a Fusion-IO raw block flash device, but
> I'm pretty sure that using a TCM RAMDISK into tcm_vhost would exhibit
> the same type of behavior.  (Will double check on that shortly..)
> 

Interestingly enough, after running some test with the vhost-scsi branch
above with the last good working commit (bdd00bd), the same fio
benchmark inline below is now reaching ~67.5K IOPs using v3.5-rc2 guest
+ host..

rw=randrw
rwmixwrite=25
rwmixread=75
size=32768m
ioengine=libaio
direct=1
iodepth=64
blocksize=4k
numjobs=2
filename=/dev/sdb


This ends up being within a few percentage of what the bare-metal HW is
capable of.. (~70K IOPs per LUN for an ioDrive Duo, Jen's CC'ed).  Note
the older QEMU vhost-scsi tree based on pre 1.1.0 code was doing ~60K
IOPs for the same test..

So this looks promising pre commit 1523ed9e1d vs. what we've been using
with vhost-scsi so far..  ;)

--nab




reply via email to

[Prev in Thread] Current Thread [Next in Thread]