public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH 2/3] virtio-pci: Use ioeventfd for virtqueue notify
Date: Sun, 14 Nov 2010 13:05:44 +0200	[thread overview]
Message-ID: <4CDFC288.9050800@redhat.com> (raw)
In-Reply-To: <AANLkTimFmt+hCt6XsDSz3V8DythW1ueUZWrrasRgpoqf@mail.gmail.com>

On 11/14/2010 12:37 PM, Stefan Hajnoczi wrote:
> On Sun, Nov 14, 2010 at 10:34 AM, Avi Kivity<avi@redhat.com>  wrote:
> >  On 11/12/2010 11:20 AM, Stefan Hajnoczi wrote:
> >>
> >>  >    Who guarantees that less common virtio-blk and virtio-net guest drivers
> >>  >    for non-Linux OSes are fine with it?  Maybe you should add a feature
> >>  >  flag
> >>  >    that the guest has to ACK to enable it.
> >>
> >>  Virtio-blk and virtio-net are fine.  Both of those devices are
> >>  expected to operate asynchronously.  SeaBIOS and gPXE virtio-net
> >>  drivers spin but they expect to and it is okay in those environments.
> >>  They already burn CPU today.
> >>
> >>  Virtio-console expects synchronous virtqueue kick.  In Linux,
> >>  virtio_console.c __send_control_msg() and send_buf() will spin.  Qemu
> >>  userspace is able to complete those requests synchronously so that the
> >>  guest never actually burns CPU (e.g.
> >>  hw/virtio-serial-bus.c:send_control_msg()).  I don't want to burn CPU
> >>  in places where we previously didn't.
> >
> >  This is a horrible bug.  virtio is an asynchronous API.  Some hypervisor
> >  implementations cannot even provide synchronous notifications.
> >
> >>  It's good that QEMU can decide whether or not to handle virtqueue kick
> >>  in the vcpu thread.  For high performance asynchronous devices like
> >>  virtio-net and virtio-blk it makes sense to use ioeventfd.  For others
> >>  it may not be useful.  I'm not sure a feature bit that exposes this
> >>  detail to the guest would be useful.
> >
> >  The guest should always assume that virtio devices are asynchronous.
>
> I agree, but let's enable virtio-ioeventfd carefully because bad code
> is out there.

Sure.  Note as long as the thread waiting on ioeventfd doesn't consume 
too much cpu, it will awaken quickly and we won't have the "transaction 
per timeslice" effect.

btw, what about virtio-blk with linux-aio?  Have you benchmarked that 
with and without ioeventfd?

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2010-11-14 11:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-11 13:47 [PATCH v2 0/3] virtio: Use ioeventfd for virtqueue notify Stefan Hajnoczi
2010-11-11 13:47 ` [PATCH 1/3] virtio-pci: Rename bugs field to flags Stefan Hajnoczi
2010-11-11 13:47 ` [PATCH 2/3] virtio-pci: Use ioeventfd for virtqueue notify Stefan Hajnoczi
2010-11-11 15:53   ` Michael S. Tsirkin
2010-11-12  9:18     ` Stefan Hajnoczi
2010-11-12  9:25       ` Michael S. Tsirkin
2010-11-12 13:10         ` Stefan Hajnoczi
2010-11-11 16:45   ` Christoph Hellwig
2010-11-12  9:20     ` [Qemu-devel] " Stefan Hajnoczi
2010-11-14 10:34       ` Avi Kivity
2010-11-14 10:37         ` Stefan Hajnoczi
2010-11-14 11:05           ` Avi Kivity [this message]
2010-11-14 12:19             ` Avi Kivity
2010-11-15 11:20               ` Stefan Hajnoczi
2010-12-01 11:44                 ` Stefan Hajnoczi
2010-12-01 12:30                   ` Avi Kivity
2010-12-01 21:34                     ` Stefan Hajnoczi
2010-12-06 15:09                       ` Avi Kivity
2010-11-11 16:59   ` Avi Kivity
2010-11-11 17:12     ` Michael S. Tsirkin
2010-11-11 17:55       ` Gleb Natapov
2010-11-11 13:47 ` [PATCH 3/3] virtio-pci: Don't use ioeventfd on old kernels Stefan Hajnoczi
2010-11-11 17:46 ` [PATCH v2 0/3] virtio: Use ioeventfd for virtqueue notify Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CDFC288.9050800@redhat.com \
    --to=avi@redhat.com \
    --cc=hch@infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox