All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: [Qemu-devel] [RFC PATCH 0/9] scsi, block: Asynchronous request cancellation
Date: Thu, 21 Aug 2014 19:56:47 +0800	[thread overview]
Message-ID: <1408622216-9578-1-git-send-email-famz@redhat.com> (raw)

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	other threads:[~2014-08-21 11:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-21 11:56 Fam Zheng [this message]
2014-08-21 11:56 ` [Qemu-devel] [RFC PATCH 1/9] block: Add bdrv_aio_cancel_async Fam Zheng
2014-08-21 12:14   ` Paolo Bonzini
2014-08-22  1:23     ` Fam Zheng
2014-08-22  8:14       ` Paolo Bonzini
2014-08-22  9:37         ` Fam Zheng
2014-08-22 10:10           ` Paolo Bonzini
2014-08-22 10:51             ` Fam Zheng
2014-08-21 13:44   ` Stefan Hajnoczi
2014-08-21 11:56 ` [Qemu-devel] [RFC PATCH 2/9] tests: Add testing code for bdrv_aio_cancel_async Fam Zheng
2014-08-21 11:56 ` [Qemu-devel] [RFC PATCH 3/9] iscsi: Implement .cancel_async in acb info Fam Zheng
2014-08-21 11:56 ` [Qemu-devel] [RFC PATCH 4/9] linux-aio: Implement .cancel_async Fam Zheng
2014-08-21 16:31   ` Stefan Hajnoczi
2014-08-22  4:56     ` Fam Zheng
2014-08-21 11:56 ` [Qemu-devel] [RFC PATCH 5/9] thread-pool: " Fam Zheng
2014-08-21 11:56 ` [Qemu-devel] [RFC PATCH 6/9] blkdebug: " Fam Zheng
2014-08-21 16:52   ` Stefan Hajnoczi
2014-08-22  4:29     ` Fam Zheng
2014-08-21 11:56 ` [Qemu-devel] [RFC PATCH 7/9] dma: " Fam Zheng
2014-08-21 11:56 ` [Qemu-devel] [RFC PATCH 8/9] block: Implement stub bdrv_em_co_aiocb_info.cancel_async Fam Zheng
2014-08-21 17:01   ` Stefan Hajnoczi
2014-08-22  4:28     ` Fam Zheng
2014-08-21 11:56 ` [Qemu-devel] [RFC PATCH 9/9] scsi: Cancel request asynchronously Fam Zheng
2014-08-21 12:19   ` Paolo Bonzini
2014-08-22  4:57     ` Fam Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1408622216-9578-1-git-send-email-famz@redhat.com \
    --to=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.