qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 2/3] virtio-pci: Use ioeventfd for virtqueue


From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [PATCH 2/3] virtio-pci: Use ioeventfd for virtqueue notify
Date: Sun, 14 Nov 2010 13:05:44 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.6

On 11/14/2010 12:37 PM, Stefan Hajnoczi wrote:
On Sun, Nov 14, 2010 at 10:34 AM, Avi Kivity<address@hidden>  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 via email to

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