From: Fam Zheng <famz@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, armbru@redhat.com, jcody@redhat.com,
qemu-devel@nongnu.org, mreitz@redhat.com,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 11/11] block: Block "device IO" during bdrv_drain and bdrv_drain_all
Date: Wed, 13 May 2015 23:17:15 +0800 [thread overview]
Message-ID: <20150513151715.GH30644@ad.nay.redhat.com> (raw)
In-Reply-To: <5553369C.9010907@redhat.com>
On Wed, 05/13 13:33, Paolo Bonzini wrote:
>
>
> On 13/05/2015 13:08, Fam Zheng wrote:
> > > I think this isn't enough. It's the callers of bdrv_drain and
> > > bdrv_drain_all that need to block before drain and unblock before
> > > aio_context_release.
> >
> > Which callers do you mean? qmp_transaction is covered in this series.
>
> All of them. :(
>
> In some cases it may be unnecessary. I'm thinking of bdrv_set_aio_context,
> and mig_save_device_dirty, but that's probably the exception rather than
> the rule.
>
> In some cases, like bdrv_snapshot_delete, the change is trivial.
>
> The only somewhat more complex case is probably block/mirror.c. There,
> the aio_context_release happens through block_job_sleep_ns or
> qemu_coroutine_yield. I guess the change would look something like
> this sketch:
>
> diff --git a/block/mirror.c b/block/mirror.c
> index 58f391a..dcfede0 100644
> --- a/block/mirror.c
> +++ b/block/mirror.c
> @@ -513,16 +513,29 @@ static void coroutine_fn mirror_run(void *opaque)
>
> if (cnt == 0 && should_complete) {
> /* The dirty bitmap is not updated while operations are pending.
> - * If we're about to exit, wait for pending operations before
> - * calling bdrv_get_dirty_count(bs), or we may exit while the
> + * If we're about to exit, wait for pending operations and
> + * recheck bdrv_get_dirty_count(bs), or we may exit while the
> * source has dirty data to copy!
> *
> * Note that I/O can be submitted by the guest while
> - * mirror_populate runs.
> + * the rest of mirror_populate runs, but we lock it out here.
> */
> trace_mirror_before_drain(s, cnt);
> +
> + // ... block ...
> bdrv_drain(bs);
> cnt = bdrv_get_dirty_count(s->dirty_bitmap);
> +
> + if (cnt == 0) {
> + /* The two disks are in sync. Exit and report successful
> + * completion.
> + */
> + assert(s->synced && QLIST_EMPTY(&bs->tracked_requests));
> + s->common.cancelled = false;
> + break; // ... and unblock somewhere else...
> + }
> +
> + // ... unblock ...
> }
>
> ret = 0;
> @@ -535,13 +549,6 @@ static void coroutine_fn mirror_run(void *opaque)
> } else if (!should_complete) {
> delay_ns = (s->in_flight == 0 && cnt == 0 ? SLICE_TIME : 0);
> block_job_sleep_ns(&s->common, QEMU_CLOCK_REALTIME, delay_ns);
> - } else if (cnt == 0) {
> - /* The two disks are in sync. Exit and report successful
> - * completion.
> - */
> - assert(QLIST_EMPTY(&bs->tracked_requests));
> - s->common.cancelled = false;
> - break;
> }
> last_pause_ns = qemu_clock_get_ns(QEMU_CLOCK_REALTIME);
> }
>
>
> It can be the topic of a separate series. But this patch brings a
> false sense of security (either the blocker is unnecessary, or it
> needs to last after bdrv_drain returns), so I think it should be
> dropped.
Doesn't this let bdrv_drain_all return when virtio-blk-dataplane is having high
workload, in places where you say "the blocker is unnecessary"?
Fam
next prev parent reply other threads:[~2015-05-13 15:17 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-13 17:28 [Qemu-devel] [PATCH v2 00/11] Fix transactional snapshot with virtio-blk dataplane and NBD export Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 01/11] block: Add op blocker type "device IO" Fam Zheng
2015-05-13 11:32 ` Wen Congyang
2015-05-13 12:04 ` Paolo Bonzini
2015-05-13 15:02 ` Fam Zheng
2015-05-13 15:09 ` Paolo Bonzini
2015-05-14 2:40 ` Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 02/11] block: Add op blocker notifier list Fam Zheng
2015-05-14 5:32 ` Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 03/11] block-backend: Add blk_op_blocker_add_notifier Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 04/11] virtio-blk: Move complete_request to 'ops' structure Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 05/11] virtio-blk: Don't handle output when there is "device IO" op blocker Fam Zheng
2015-05-13 10:26 ` Paolo Bonzini
2015-05-13 11:09 ` Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 06/11] nbd-server: Clear "can_read" when "device io" blocker is set Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 07/11] blockdev: Block device IO during internal snapshot transaction Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 08/11] blockdev: Block device IO during external " Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 09/11] blockdev: Block device IO during drive-backup transaction Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 10/11] blockdev: Block device IO during blockdev-backup transaction Fam Zheng
2015-05-13 11:22 ` Wen Congyang
2015-05-13 12:55 ` Fam Zheng
2015-05-14 1:12 ` Wen Congyang
2015-05-14 1:53 ` Fam Zheng
2015-05-13 12:21 ` Paolo Bonzini
2015-05-13 15:08 ` Paolo Bonzini
2015-05-13 15:34 ` Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 11/11] block: Block "device IO" during bdrv_drain and bdrv_drain_all Fam Zheng
2015-05-13 10:26 ` Paolo Bonzini
2015-05-13 11:08 ` Fam Zheng
2015-05-13 11:33 ` Paolo Bonzini
2015-05-13 15:17 ` Fam Zheng [this message]
2015-05-13 15:25 ` Paolo Bonzini
2015-05-14 3:02 ` 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=20150513151715.GH30644@ad.nay.redhat.com \
--to=famz@redhat.com \
--cc=armbru@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--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 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).