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

[Anthony Liguori]

Paolo Bonzini <address@hidden> writes:

> Il 09/10/2012 17:02, Anthony Liguori ha scritto:
>> We've discussed previously about having an additional layer on top of
>> the block API.
>> 
>> One problem with the block API today is that it doesn't distinguish
>> between device access and internal access.  I think this is an
>> opportunity to introduce a device-only API.
>
> And what API would libqblock use?

!device-only API

> I don't think this is a good idea unless we can prove performance problems.

Let's separate out the two things.

A device specific API has some advantages.  I'm pretty sure it's a hard
requirement for Kemari (they need to use device I/O as quiescent
points).  It makes testing easier too (simplier interface).

But it also lets us do a short-term hack.  That's all I'm suggesting
here.  A short term fast path.

>> In the very short term, I can imagine an aio fastpath that was only
>> implemented in terms of the device API.  We could have a slow path that
>> acquired the BQL.
>
> Not sure I follow.

As long as the ioeventfd thread can acquire qemu_mutex in order to call
bdrv_* functions.  The new device-only API could do this under the
covers for everything but the linux-aio fast path initially.

That means that we can convert block devices to use the device-only API
across the board (provided we make BQL recursive).

It also means we get at least some of the benefits of data-plane in the
short term.

>> > 4. Unlocked event loop thread.  This is simlar to QEMU's iothread except it
>> >    doesn't take the big lock.  In theory we could have several of these 
>> > threads
>> >    processing at the same time.  virtio-blk ioeventfd processing will be 
>> > done
>> >    in this thread.
>> 
>> I think we're reasonable close to being able to do this FWIW.
>
> Yes, I'm resending this series with your comments addressed.  It strays
> a bit between your territory (main-loop) and Kevin's, I'll let you two
> sort it out.

I was very happy with it so as long as Kevin is willing to Ack it, I'm
happy to apply it.

Regards,

Anthony Liguori

>
> Paolo