qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Zhi Yong Wu <wuzhy@cn.ibm.com>, Avi Kivity <avi@redhat.com>,
	Christoph Hellwig <hch@lst.de>
Subject: [Qemu-devel] [PATCH 0/6] block: do request processing in a coroutine
Date: Wed,  5 Oct 2011 17:17:01 +0100	[thread overview]
Message-ID: <1317831427-477-1-git-send-email-stefanha@linux.vnet.ibm.com> (raw)

Block layer features like dirty block tracing, I/O throttling, and live block
copy are forced to duplicate code due to the three different interfaces:
synchronous, asynchronous, and coroutines.

Since there are bdrv_read(), bdrv_aio_readv(), and bdrv_co_readv() interfaces
for read (and similar for write), per-request processing needs to be duplicated
for each of these execution contexts.  For example, dirty block tracking code
is duplicated across these three interfaces.

This patch series unifies request processing so that there is only one code
path.  I see this as a prerequisite to the live block copy (image streaming)
code I am working on, so I'm pushing it now.

The short-term win from this series is that it becomes easy to add live block
copy and other features.  We now have a single code path where the perf-request
processing is done.

The longer-term win will be dropping the BlockDriver .bdrv_read(),
.bdrv_write(), .bdrv_aio_readv(), and .bdrv_aio_writev() interfaces.  By doing
that we can bring all BlockDrivers onto a common interface, namely
.bdrv_co_readv() and .bdrv_co_writev().  It will also allow us to drop most of
the sync and aio emulation code.

A consequence of this patch series is that every I/O request goes through at
least one coroutine.  There is no longer a direct .bdrv_read(), .bdrv_write(),
.bdrv_aio_readv(), or .bdrv_aio_writev() call - we're trying to phase out those
interfaces.  I have not noticed performance degradation in correctness tests
but we need to confirm that there has not been a performance regression.

Stefan Hajnoczi (6):
  block: directly invoke .bdrv_aio_*() in bdrv_co_io_em()
  block: split out bdrv_co_do_readv() and bdrv_co_do_writev()
  block: switch bdrv_read()/bdrv_write() to coroutines
  block: switch bdrv_aio_readv() to coroutines
  block: mark blocks dirty on coroutine write completion
  block: switch bdrv_aio_writev() to coroutines

 block.c |  273 +++++++++++++++++++++++++++++++--------------------------------
 1 files changed, 134 insertions(+), 139 deletions(-)

-- 
1.7.6.3

             reply	other threads:[~2011-10-05 16:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-05 16:17 Stefan Hajnoczi [this message]
2011-10-05 16:17 ` [Qemu-devel] [PATCH 1/6] block: directly invoke .bdrv_aio_*() in bdrv_co_io_em() Stefan Hajnoczi
2011-10-05 16:17 ` [Qemu-devel] [PATCH 2/6] block: split out bdrv_co_do_readv() and bdrv_co_do_writev() Stefan Hajnoczi
2011-10-05 16:17 ` [Qemu-devel] [PATCH 3/6] block: switch bdrv_read()/bdrv_write() to coroutines Stefan Hajnoczi
2011-10-11  6:44   ` Zhi Yong Wu
2011-10-12  9:03     ` Stefan Hajnoczi
2011-10-12  9:11       ` Zhi Yong Wu
2011-10-12 12:53   ` Kevin Wolf
2011-10-05 16:17 ` [Qemu-devel] [PATCH 4/6] block: switch bdrv_aio_readv() " Stefan Hajnoczi
2011-10-12 13:07   ` Kevin Wolf
2011-10-05 16:17 ` [Qemu-devel] [PATCH 5/6] block: mark blocks dirty on coroutine write completion Stefan Hajnoczi
2011-10-05 16:17 ` [Qemu-devel] [PATCH 6/6] block: switch bdrv_aio_writev() to coroutines Stefan Hajnoczi
2011-10-11  6:46   ` Zhi Yong Wu
2011-10-11  6:49 ` [Qemu-devel] [PATCH 0/6] block: do request processing in a coroutine Zhi Yong Wu
2011-10-12 13:21 ` Kevin Wolf

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=1317831427-477-1-git-send-email-stefanha@linux.vnet.ibm.com \
    --to=stefanha@linux.vnet.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=hch@lst.de \
    --cc=kwolf@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wuzhy@cn.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).