All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alberto Garcia <berto@igalia.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v10 01/16] block: Pause all jobs during bdrv_reopen_multiple()
Date: Tue, 11 Oct 2016 13:07:14 +0200	[thread overview]
Message-ID: <20161011110714.GD6334@noname.redhat.com> (raw)
In-Reply-To: <d3346d99-e67f-b7b9-7d80-78be044ecd9d@redhat.com>

Am 11.10.2016 um 11:54 hat Paolo Bonzini geschrieben:
> On 11/10/2016 11:39, Kevin Wolf wrote:
> > Am 10.10.2016 um 18:41 hat Paolo Bonzini geschrieben:
> >> On 10/10/2016 17:37, Kevin Wolf wrote:
> >>>> +    while ((job = block_job_next(job))) {
> >>>> +        AioContext *aio_context = blk_get_aio_context(job->blk);
> >>>> +
> >>>> +        aio_context_acquire(aio_context);
> >>>> +        block_job_pause(job);
> >>>> +        aio_context_release(aio_context);
> >>>> +    }
> >>>> +
> >>>>      bdrv_drain_all();
> >>>
> >>> We already have a bdrv_drain_all() here, which does the same thing (and
> >>> more) internally, except that it resumes all jobs before it returns.
> >>> Maybe what we should do is split bdrv_drain_all() in a begin/end pair,
> >>> too.
> >>
> >> Hey, haven't I just suggested the same? :)  I swear I hadn't read this
> >> before.
> >>
> >>> The other point I'm wondering now is whether bdrv_drain_all() should
> >>> have the aio_disable/enable_external() pair that bdrv_drain() has.
> >>
> >> bdrv_drain_all need not have it, but its start/end replacement should.
> > 
> > Doesn't need it because it holds the AioContext lock?
> 
> No, because as soon as bdrv_drain_all exits, external file descriptors
> can be triggered again so I don't think the aio_disable/enable_external
> actually provides any protection.

Right, what I was thinking of was more like new requests coming in
while bdrv_drain_all() is still running. If that happened, the result
after bdrv_drain_all() wouldn't be different, but if external file
descriptors are still active and the guest keeps sending requests, it
could take forever until it returns.

But that part is addressed by the AioContext lock, I think.

> bdrv_drain_all should really only be used in cases where you already
> have some kind of "hold" on external file descriptors, like bdrv_close
> uses bdrv_drain():
> 
>     bdrv_drained_begin(bs); /* complete I/O */
>     bdrv_flush(bs);
>     bdrv_drain(bs); /* in case flush left pending I/O */
> 
> That said, because the simplest implementation of bdrv_drain_all() does
> 
>     bdrv_drained_all_start();
>     bdrv_drained_all_end();
> 
> just like bdrv_drain() does it, it's not a very interesting point.
> bdrv_drain_all will probably disable/enable external file descriptors,
> it just doesn't need that.

Yes, of course.

Kevin

  reply	other threads:[~2016-10-11 11:07 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-06 13:02 [Qemu-devel] [PATCH v10 00/16] Support streaming to an intermediate layer Alberto Garcia
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 01/16] block: Pause all jobs during bdrv_reopen_multiple() Alberto Garcia
2016-10-10 15:37   ` Kevin Wolf
2016-10-10 16:41     ` Paolo Bonzini
2016-10-11  9:39       ` Kevin Wolf
2016-10-11  9:54         ` Paolo Bonzini
2016-10-11 11:07           ` Kevin Wolf [this message]
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 02/16] block: Add block_job_add_bdrv() Alberto Garcia
2016-10-10 15:46   ` Kevin Wolf
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 03/16] block: Use block_job_add_bdrv() in mirror_start_job() Alberto Garcia
2016-10-10 16:03   ` Kevin Wolf
2016-10-11  8:20     ` Paolo Bonzini
2016-10-11 13:46     ` Alberto Garcia
2016-10-11 14:01       ` Kevin Wolf
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 04/16] block: Use block_job_add_bdrv() in backup_start() Alberto Garcia
2016-10-12 13:47   ` Kevin Wolf
2016-10-12 13:57     ` Alberto Garcia
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 05/16] block: Check blockers in all nodes involved in a block-commit job Alberto Garcia
2016-10-12 13:47   ` Kevin Wolf
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 06/16] block: Block all nodes involved in the block-commit operation Alberto Garcia
2016-10-12 13:54   ` Kevin Wolf
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 07/16] block: Block all intermediate nodes in commit_active_start() Alberto Garcia
2016-10-12 14:06   ` Kevin Wolf
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 08/16] block: Support streaming to an intermediate layer Alberto Garcia
2016-10-12 14:23   ` Kevin Wolf
2016-10-12 14:33     ` Alberto Garcia
2016-10-12 14:45       ` Kevin Wolf
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 09/16] block: Add QMP support for " Alberto Garcia
2016-10-10 19:09   ` Eric Blake
2016-10-11 14:30     ` Alberto Garcia
2016-10-11 14:57       ` Kevin Wolf
2016-10-11 15:53         ` Eric Blake
2016-10-11 16:50           ` Markus Armbruster
2016-10-12  9:11             ` Kevin Wolf
2016-10-12  9:25             ` Alberto Garcia
2016-10-11 16:32         ` Markus Armbruster
2016-10-12  9:28           ` Alberto Garcia
2016-10-12 12:17             ` Markus Armbruster
2016-10-12 14:30   ` Kevin Wolf
2016-10-12 14:48     ` Alberto Garcia
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 10/16] docs: Document how to stream " Alberto Garcia
2016-10-12 14:39   ` Kevin Wolf
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 11/16] qemu-iotests: Test streaming " Alberto Garcia
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 12/16] qemu-iotests: Test block-stream operations in parallel Alberto Garcia
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 13/16] qemu-iotests: Test overlapping stream and commit operations Alberto Garcia
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 14/16] qemu-iotests: Test block-stream and block-commit in parallel Alberto Garcia
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 15/16] qemu-iotests: Add iotests.supports_quorum() Alberto Garcia
2016-10-06 13:02 ` [Qemu-devel] [PATCH v10 16/16] qemu-iotests: Test streaming to a Quorum child Alberto Garcia

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=20161011110714.GD6334@noname.redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berto@igalia.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 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.