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