[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 00/22] block: Asynchronous request cancellati
From: |
Fam Zheng |
Subject: |
Re: [Qemu-devel] [PATCH v5 00/22] block: Asynchronous request cancellation |
Date: |
Wed, 10 Sep 2014 17:20:15 +0800 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Wed, 09/10 17:09, Bin Wu wrote:
> On 2014/9/10 13:59, Fam Zheng wrote:
> >v5: Fix IDE callback. (Paolo)
> > Fix blkdebug. (Paolo)
> > Drop the DMA fix which is independent of this series. (Paolo)
> > Incorperate Yuan's patch on quorum_aio_cancel. (Benoît)
> > Commit message wording fix. (Benoît)
> > Rename qemu_aio_release to qemu_aio_unref. (Benoît)
> >
> >v4: Drop AIOCBInfo.cancel.
> >
> >This series adds a new block layer API:
> >
> > void bdrv_aio_cancel_async(BlockDriverAIOCB *acb);
> >
> >And use it to emulate bdrv_aio_cancel.
> >
> >The function is similar to bdrv_aio_cancel in that it cancels an AIO request,
> >but different that it doesn't block until the request is completely cancelled
> >or done.
> >
> >More importantly, the completion callback, BlockDriverAIOCB.cb, is guaranteed
> >to be called, so that the cb can take care of resource releasing and status
> >reporting to guest, etc.
> >
> >In the following work, scsi emulation code will be shifted to use the async
> >cancelling.
> >
> >One major benefit would be that when guest tries to cancel a request, where
> >the
> >request cannot be cancelled easily, (due to throttled BlockDriverState, a
> >lost
> >connection, or a large request queue), we don't need to block the whole vm
> >with
> >a busy loop, which is how bdrv_aio_cancel is implemented now.
>
> First, I think this series is really useful. However, I tested the v4 series
> and found virtio-scsi disk(scsi-hd) was still blocked when the IO could not
> come back because of virtio_scsi_do_tmf->scsi_cancel_io->bdrv_aio_cancel.
> can we just change the bdrv_aio_cancel to bdrv_aio_cancel_async to solve
> this problem?
We can't just change it yet. We need to take care of the scsi_req_unref there,
if we unref right after bdrv_aio_cancel_async, in the cb it will access
dangling pointer.
It's not trivial enough to do in this series, I will work on that on top, as
said below. For now, the user visible behavior of io cancellation is still the
same.
Thanks for testing.
Fam
> >
> >Later, we will change scsi device code to make this asynchronous, on top of
> >bdrv_aio_cancel_async.
- [Qemu-devel] [PATCH v5 15/22] quorum: fix quorum_aio_cancel(), (continued)
- [Qemu-devel] [PATCH v5 15/22] quorum: fix quorum_aio_cancel(), Fam Zheng, 2014/09/10
- [Qemu-devel] [PATCH v5 16/22] quorum: Convert quorum_aiocb_info.cancel to .cancel_async, Fam Zheng, 2014/09/10
- [Qemu-devel] [PATCH v5 17/22] rbd: Drop rbd_aiocb_info.cancel, Fam Zheng, 2014/09/10
- [Qemu-devel] [PATCH v5 18/22] sheepdog: Convert sd_aiocb_info.cancel to .cancel_async, Fam Zheng, 2014/09/10
- [Qemu-devel] [PATCH v5 19/22] win32-aio: Drop win32_aiocb_info.cancel, Fam Zheng, 2014/09/10
- [Qemu-devel] [PATCH v5 20/22] ide: Convert trim_aiocb_info.cancel to .cancel_async, Fam Zheng, 2014/09/10
- [Qemu-devel] [PATCH v5 21/22] block: Drop AIOCBInfo.cancel, Fam Zheng, 2014/09/10
- [Qemu-devel] [PATCH v5 22/22] block: Rename qemu_aio_release -> qemu_aio_unref, Fam Zheng, 2014/09/10
- [Qemu-devel] [PATCH v5 12/22] blkverify: Drop blkverify_aiocb_info.cancel, Fam Zheng, 2014/09/10
- Re: [Qemu-devel] [PATCH v5 00/22] block: Asynchronous request cancellation, Bin Wu, 2014/09/10
- Re: [Qemu-devel] [PATCH v5 00/22] block: Asynchronous request cancellation,
Fam Zheng <=