Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts""

[Avi Kivity]

On 10/09/2012 12:36 PM, Paolo Bonzini wrote:
> Il 09/10/2012 11:26, Avi Kivity ha scritto:
>> On 10/09/2012 11:08 AM, Stefan Hajnoczi wrote:
>>> Here are the steps that have been mentioned:
>>>
>>> 1. aio fastpath - for raw-posix and other aio block drivers, can we reduce 
>>> I/O
>>>    request latency by skipping block layer coroutines?  
>> 
>> Is coroutine overhead noticable?
> 
> I'm thinking more about throughput than latency.  If the iothread
> becomes CPU-bound, then everything is noticeable.

That's not strictly a coroutine issue.  Switching to ordinary threads
may make the problem worse, since there will clearly be contention.

What is the I/O processing time we have?  If it's say 10 microseconds,
then we'll have 100,000 context switches per second assuming a device
lock and a saturated iothread (split into multiple threads).

The coroutine work may have laid the groundwork for fine-grained
locking.  I'm doubtful we should use qcow when we want >100K IOPS though.

> 
>>> I'm also curious about virtqueue_pop()/virtqueue_push() outside the QEMU 
>>> mutex
>>> although that might be blocked by the current work around MMIO/PIO dispatch
>>> outside the global mutex.
>> 
>> It is, yes.
> 
> It should only require unlocked memory map/unmap, not MMIO dispatch.
> The MMIO/PIO bits are taken care of by ioeventfd.

The ring, or indirect descriptors, or the data, can all be on mmio.
IIRC the virtio spec forbids that, but the APIs have to be general.  We
don't have cpu_physical_memory_map_nommio() (or
address_space_map_nommio(), as soon as the coding style committee
ratifies srtuct literals).

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