From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
qemu-devel@nongnu.org, Zhi Yong Wu <wuzhy@cn.ibm.com>,
Avi Kivity <avi@redhat.com>, Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH 0/6] block: do request processing in a coroutine
Date: Wed, 12 Oct 2011 15:21:27 +0200 [thread overview]
Message-ID: <4E959457.2000300@redhat.com> (raw)
In-Reply-To: <1317831427-477-1-git-send-email-stefanha@linux.vnet.ibm.com>
Am 05.10.2011 18:17, schrieb Stefan Hajnoczi:
> 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(-)
>
Except for breaking synchronous drivers this looks good.
I have applied the first two patches to the block branch, so if you
don't need to change them, submitting patches 3-6 for v2 will be enough.
Kevin
prev parent reply other threads:[~2011-10-12 13:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-05 16:17 [Qemu-devel] [PATCH 0/6] block: do request processing in a coroutine Stefan Hajnoczi
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 [this message]
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=4E959457.2000300@redhat.com \
--to=kwolf@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=hch@lst.de \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.com \
--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 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.