qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	qemu-block@nongnu.org, Ed Swierk <eswierk@skyportsystems.com>,
	Max Reitz <mreitz@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH for-2.9 3/5] block: Quiesce old aio context during bdrv_set_aio_context
Date: Fri, 7 Apr 2017 10:15:05 +0200	[thread overview]
Message-ID: <20170407081505.GA4716@noname.redhat.com> (raw)
In-Reply-To: <20170406234426.GD4618@lemon>

Am 07.04.2017 um 01:44 hat Fam Zheng geschrieben:
> On Thu, 04/06 17:17, Kevin Wolf wrote:
> > Am 06.04.2017 um 16:25 hat Fam Zheng geschrieben:
> > > The fact that the bs->aio_context is changing can confuse the dataplane
> > > iothread, because of the now fine granularity aio context lock.
> > > bdrv_drain should rather be a bdrv_drained_begin/end pair, but since
> > > bs->aio_context is changing, we can just use aio_disable_external and
> > > block_job_pause.
> > > 
> > > Reported-by: Ed Swierk <eswierk@skyportsystems.com>
> > > Signed-off-by: Fam Zheng <famz@redhat.com>
> > > ---
> > >  block.c | 11 +++++++++--
> > >  1 file changed, 9 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/block.c b/block.c
> > > index 8893ac1..e70684a 100644
> > > --- a/block.c
> > > +++ b/block.c
> > > @@ -4395,11 +4395,14 @@ void bdrv_attach_aio_context(BlockDriverState *bs,
> > >  
> > >  void bdrv_set_aio_context(BlockDriverState *bs, AioContext *new_context)
> > >  {
> > > -    AioContext *ctx;
> > > +    AioContext *ctx = bdrv_get_aio_context(bs);
> > >  
> > > +    aio_disable_external(ctx);
> > > +    if (bs->job) {
> > > +        block_job_pause(bs->job);
> > > +    }
> > 
> > Even more bs->job users... :-(
> > 
> > But is this one actually necessary? We drain all pending BHs below, so
> > the job shouldn't have any requests in flight or be able to submit new
> > ones while we switch.
> 
> I'm not 100% sure, but I think the aio_poll() loop below can still fire
> co_sleep_cb if we don't do block_job_pause()?

Somehow I thought that aio_poll() doesn't run timers, but that seems to
be wrong. I think in the pre-AioContext world it used to be this way.

Okay, let's leave this patch as it is. We can then clean things up in
the 2.10 timeframe and propagate things cleanly upwards through the
BlockBackend to its users. We want to this for drain anyway.

Hm, maybe we should already call bdrv_parent_drained_begin/end? I don't
think that image throttling can submit new requests while we're changing
the AioContext (because it probably doesn't have any at that point), but
I'm not completely sure.

Kevin

  reply	other threads:[~2017-04-07  8:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-06 14:25 [Qemu-devel] [PATCH for-2.9 0/5] block: Fixes regarding dataplane and management operations Fam Zheng
2017-04-06 14:25 ` [Qemu-devel] [PATCH for-2.9 1/5] block: Fix unpaired aio_disable_external in external snapshot Fam Zheng
2017-04-06 14:36   ` Eric Blake
2017-04-06 14:36   ` Kevin Wolf
2017-04-06 23:38     ` Fam Zheng
2017-04-06 14:25 ` [Qemu-devel] [PATCH for-2.9 2/5] mirror: Fix aio context of mirror_top_bs Fam Zheng
2017-04-06 14:36   ` Eric Blake
2017-04-06 14:37   ` Kevin Wolf
2017-04-06 14:25 ` [Qemu-devel] [PATCH for-2.9 3/5] block: Quiesce old aio context during bdrv_set_aio_context Fam Zheng
2017-04-06 15:00   ` Eric Blake
2017-04-06 15:17   ` Kevin Wolf
2017-04-06 23:44     ` Fam Zheng
2017-04-07  8:15       ` Kevin Wolf [this message]
2017-04-06 14:25 ` [Qemu-devel] [PATCH for-2.9 4/5] block: Drain BH in bdrv_drained_begin Fam Zheng
2017-04-06 15:10   ` Eric Blake
2017-04-06 15:37   ` Kevin Wolf
2017-04-14  9:15     ` Paolo Bonzini
2017-04-06 14:25 ` [Qemu-devel] [PATCH for-2.9 5/5] coroutine: Explicitly specify AioContext when creating coroutine Fam Zheng
2017-04-06 15:34   ` Eric Blake
2017-04-06 16:20   ` Kevin Wolf
2017-04-07  8:34     ` 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=20170407081505.GA4716@noname.redhat.com \
    --to=kwolf@redhat.com \
    --cc=eswierk@skyportsystems.com \
    --cc=famz@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).