[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC][PATCH 9/9] block: Use bdrv_co_* instead of synchr
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [RFC][PATCH 9/9] block: Use bdrv_co_* instead of synchronous versions in coroutines |
Date: |
Fri, 22 Jul 2011 12:00:13 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc15 Thunderbird/3.1.11 |
Am 22.07.2011 11:17, schrieb Stefan Hajnoczi:
> On Fri, Jul 22, 2011 at 7:48 AM, Kevin Wolf <address@hidden> wrote:
>> Am 21.07.2011 17:23, schrieb Stefan Hajnoczi:
>>> On Fri, Jul 15, 2011 at 06:47:39PM +0200, Kevin Wolf wrote:
>>>> If we're already in a coroutine, there is no reason to use the synchronous
>>>> version of block layer functions when a coroutine one exists. This makes
>>>> bdrv_read/write/flush use bdrv_co_* when used inside a coroutine.
>>>>
>>>> Signed-off-by: Kevin Wolf <address@hidden>
>>>> ---
>>>> block.c | 43 +++++++++++++++++++++++++++++++++++++++++++
>>>> 1 files changed, 43 insertions(+), 0 deletions(-)
>>>
>>> I made similar changes to prototype qcow2 coroutines. They allowed
>>> synchronous code to run unmodified inside a coroutine.
>>>
>>> But do we want to keep the synchronous APIs? They tend to be misused
>>> because they allow synchronous implementation of devices (extboot,
>>> onenand, and others).
>>>
>>> The only reason to keep these around is for qemu-img and perhaps some
>>> startup code before the VM is running. But I think we could tackle
>>> those cases too simply by running in a coroutine and using a common
>>> event loop (which makes timers and bottom halves work too).
>>
>> One change at a time. :-)
>>
>> This series is manageable, can be reviewed in finite time and gives us
>> the immediate benefit of not blocking the VCPU any more. I know that
>> some tend to rewrite half of qemu for every idea they have, but I'd
>> prefer a more incremental approach.
>
> Fair enough. I just want to make sure that we're working in the
> direction of removing the synchronous stuff rather than propping it
> up.
Sure, I'm just trying to find an incremental approach to do it.
>> Removing all synchronous bdrv_read/write calls from the devices is a
>> task that I wouldn't underestimate, and at the same time a completely
>> unrelated task (you could have suggested the same with AIO callbacks). I
>> agree that we should do this change some time, but for now devices get
>> exactly what they got before.
>
> AIO interfaces should be kept because they do not have drawbacks like
> synchronous interfaces. The AIO interfaces provide the most efficient
> way of implementing raw.
Sorry, my wording was ambiguous. I meant you could have argued before
that synchronous bdrv_read/write calls in the device should be replaced
by AIO ones. It's not something entirely new that only coroutines
provide, they just provide it in a nicer way.
Kevin
- [Qemu-devel] [RFC][PATCH 3/9] block: Add bdrv_co_readv/writev emulation, (continued)
- [Qemu-devel] [RFC][PATCH 3/9] block: Add bdrv_co_readv/writev emulation, Kevin Wolf, 2011/07/15
- [Qemu-devel] [RFC][PATCH 4/9] coroutines: Locks, Kevin Wolf, 2011/07/15
- [Qemu-devel] [RFC][PATCH 5/9] qcow2: Use coroutines, Kevin Wolf, 2011/07/15
- [Qemu-devel] [RFC][PATCH 6/9] qcow: Use coroutines, Kevin Wolf, 2011/07/15
- [Qemu-devel] [RFC][PATCH 8/9] coroutines: Use one global bottom half for CoQueue, Kevin Wolf, 2011/07/15
- [Qemu-devel] [RFC][PATCH 7/9] async: Remove AsyncContext, Kevin Wolf, 2011/07/15
- [Qemu-devel] [RFC][PATCH 9/9] block: Use bdrv_co_* instead of synchronous versions in coroutines, Kevin Wolf, 2011/07/15