qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [RFC PATCH 0/9] scsi, block: Asynchronous request cancellat


From: Fam Zheng
Subject: [Qemu-devel] [RFC PATCH 0/9] scsi, block: Asynchronous request cancellation
Date: Thu, 21 Aug 2014 19:56:47 +0800

This series adds a new block API:

  void bdrv_aio_cancel_async(BlockDriverAIOCB *acb);

which is similar to existing 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.

Because of this, 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.

The first patches introduces the interface and a (default) degradad
implementation, which is emulated with bdrv_aio_cancel.

Then some testing on it is added in patch 2.

Following patches are the implementation of .cancel_async in several AIOCBInfo
structures. Note that blkldebug's and iscsi's implementations are not tested,
just for the purpose to see what it takes to implement it. In the long term, we
may consider completely dropping bdrv_aio_cancel, if it turns out the
asynchronous version works better. The callers are not many, and it feels
counterintuitive to have a synchronous bdrv_aio_* function.

In the end, scsi emulation code is shifted to the async cancelling.

One major benefit is 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 no longer need to block the whole
vm with a busy wait polling loop, which is how bdrv_aio_cancel is implemented
now.

To test this series, you can throttle a scsi-disk to a very low limit, for
example 50 bps, then stress the guest block device with dd or fio.

Before, the vm will quickly hang when it loses patience and sends a tmf command
to cancel the request, at which point we will spin in bdrv_aio_cancel, until
the request is slowly spit out from throttled_reqs.

After, the guest is not blocked, so the responsiveness of the VM is much
better.

The same applies for a disappeared/hung (nfs, iscsi, etc.) storage target.

Last but not least, the remaing users of bdrv_aio_cancel, after this series,
are only 4:

    block/quorum.c
    hw/block/nvme.c
    hw/ide/ahci.c
    hw/ide/core.c

I said too many things that you already knew. Please review and make any
comments! Thank you very much!

Fam


Fam Zheng (9):
  block: Add bdrv_aio_cancel_async
  tests: Add testing code for bdrv_aio_cancel_async
  iscsi: Implement .cancel_async in acb info
  linux-aio: Implement .cancel_async
  thread-pool: Implement .cancel_async
  blkdebug: Implement .cancel_async
  dma: Implement .cancel_async
  block: Implement stub bdrv_em_co_aiocb_info.cancel_async
  scsi: Cancel request asynchronously

 block.c                  | 40 +++++++++++++++++++++++++++++++++
 block/blkdebug.c         | 20 +++++++++++------
 block/iscsi.c            | 18 ++++++++++++---
 block/linux-aio.c        | 20 +++++++++++++++--
 dma-helpers.c            | 28 +++++++++++++++++++++++
 hw/scsi/scsi-bus.c       |  6 ++---
 hw/scsi/scsi-disk.c      | 41 +++++++++-------------------------
 hw/scsi/scsi-generic.c   | 21 +++++-------------
 include/block/aio.h      |  2 ++
 include/block/block.h    |  1 +
 tests/test-thread-pool.c | 39 +++++++++++++++++++++++++-------
 thread-pool.c            | 58 +++++++++++++++++++++++++++++++++++++++---------
 12 files changed, 213 insertions(+), 81 deletions(-)

-- 
2.0.3




reply via email to

[Prev in Thread] Current Thread [Next in Thread]