[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC P
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"" |
Date: |
Tue, 09 Oct 2012 10:37:33 -0500 |
User-agent: |
Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) |
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
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", (continued)
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Avi Kivity, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Paolo Bonzini, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Avi Kivity, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Paolo Bonzini, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Avi Kivity, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Paolo Bonzini, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Avi Kivity, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Stefan Hajnoczi, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Anthony Liguori, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Paolo Bonzini, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"",
Anthony Liguori <=
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Paolo Bonzini, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Anthony Liguori, 2012/10/09
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Paolo Bonzini, 2012/10/10
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Anthony Liguori, 2012/10/10
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Paolo Bonzini, 2012/10/10
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Anthony Liguori, 2012/10/10
- Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [RFC PATCH 00/17] Support for multiple "AIO contexts"", Kevin Wolf, 2012/10/11