Re: [Qemu-devel] converting the block layer from coroutines to threads

[Paolo Bonzini <pbonzini@redhat.com>]

Il 24/02/2012 22:01, Anthony Liguori ha scritto:
>> Once you can issue I/O from two threads at the same-time (such as
>> streaming in the iothread and guest I/O in the virtqueue thread),
>> everything already needs to be thread-safe.  It is a pretty short step
>> from there to thread pools for everything.
> 
> If you start with a thread safe API for submitting block requests, that
> could be implemented as
> 
> bapi_aiocb *bapi_submit_readv(bapi_driver *d, struct iovec *iov, int
> iovcnt,
>                               off_t offset)
> {
>    bapi_request *req = make_bapi_request(BAPI_READ, iov, iovcnt, offset);
> 
>    return bapi_queue_add_req(req);
> }
> 
> Which would schedule the I/O thread to actually implement the
> operation.  You could then start incrementally refactoring specific
> drivers to be re-entrant (like linux-aio).

My proposal has exactly these two ingredients: a representations of
block layer requests, and a fast path for AIO.

But there are really two complementary parts to it.  One is generalizing
thread-pool support to non-raw formats, the other is doing I/O from
multiple threads at the same time.  The first is quite easy overall.
The second is hard, because it's not just about reentrancy.  You need
various pieces of infrastructure that do not yet exist; for example you
need freeze/unfreeze, because drain/drain_all is not enough if other
threads can submit I/O concurrently.

> But anything that already needs to use a thread pool to do its I/O
> probably wouldn't benefit from threading virtio.

Linux AIO _is_ a thread-pool in the end.  It is surprising how close the
latencies are between io_submit and cond_signal, for example.

Paolo