qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 10/12] block: Drain throttling queue with BdrvChild callback
Date: Thu, 24 Mar 2016 09:25:10 +0100	[thread overview]
Message-ID: <20160324082510.GB4310@noname.redhat.com> (raw)
In-Reply-To: <56F30A9F.6040300@redhat.com>

Am 23.03.2016 um 22:29 hat Paolo Bonzini geschrieben:
> 
> 
> On 22/03/2016 16:33, Kevin Wolf wrote:
> > This removes the last part of I/O throttling from block/io.c and moves
> > it to the BlockBackend.
> > 
> > When draining the queue of a BlockDriverState, we must make sure that no
> > new requests can come in for it. Request sources from outside the block
> > layer are disabled with aio_disable_external(), but the throttling queue
> > must be handled separately.
> 
> I have looked at the strategy we talked about today to implement request
> cancellation (so that e.g. system reset doesn't take ages because of
> throttled requests).  While that may be a worthwhile addition anyway, I
> think throttling bdrv_drain() may impose an excessive cost for cases
> such as live migration.  The risk of the guest using bdrv_drain() to
> game throttling is low enough that we can keep on disabling throttling
> during bdrv_drain().

I think your cancellation series (allows to) gets rid of most if not all
blk_drain() callers in the device emulation, so it becomes harder for
guests to trigger one. Ideally only the monitor should allow triggering
a drain.

On the other hand, your other series introduces bdrv_drain() calls where
we have open-coded nested event loops waiting for a single request
today. I'm pretty sure that these can be triggered by the guest and that
throttling the drain would be desirable therefore. Maybe we need a
different function there, and maybe we can even retain the behaviour
that it doesn't unnecessarily flush everything instead of just waiting
for the completion of a single request.

> So for now I think we can merge the two series just fine.  The strategy
> I used in my patch, adding bdrv_no_throttling_begin and
> bdrv_no_throttling_end around the bdrv_drain loop, can be adapted just
> as use BdrvChildRole callbacks ->drained_begin and ->drained_end.

Okay. Actually, such a pair of callbacks - not only into the
BlockBackend, but from there into the guest device - was a thought
already when we introduced aio_disable_external(). Do you think it would
make sense to change things in the mid term so that the users of a
BlockBackend just get drain_begin/end callbacks?

> I will post v3 of my series tomorrow, adopting your patch 1/12 of this
> series and removing the recursion on bdrv_no_throttling_begin and
> bdrv_no_throttling_end, which is unnecessary.

Okay, I'll try to rebase then.

Kevin

  reply	other threads:[~2016-03-24  8:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-22 15:33 [Qemu-devel] [PATCH 00/12] block: Move I/O throttling to BlockBackend Kevin Wolf
2016-03-22 15:33 ` [Qemu-devel] [PATCH 01/12] block: Don't disable I/O throttling on sync requests Kevin Wolf
2016-03-22 21:40   ` Eric Blake
2016-03-22 15:33 ` [Qemu-devel] [PATCH 02/12] block: Make sure throttled BDSes always have a BB Kevin Wolf
2016-03-22 21:46   ` Eric Blake
2016-03-22 15:33 ` [Qemu-devel] [PATCH 03/12] block: Introduce BlockBackendPublic Kevin Wolf
2016-03-22 21:53   ` Eric Blake
2016-03-23  9:09     ` Kevin Wolf
2016-03-23 21:35       ` Eric Blake
2016-03-24  8:06         ` Kevin Wolf
2016-03-22 15:33 ` [Qemu-devel] [PATCH 04/12] block: throttle-groups: Use BlockBackend pointers internally Kevin Wolf
2016-03-22 15:33 ` [Qemu-devel] [PATCH 05/12] block: Convert throttle_group_get_name() to BlockBackend Kevin Wolf
2016-03-22 15:33 ` [Qemu-devel] [PATCH 06/12] block: Move throttling fields from BDS to BB Kevin Wolf
2016-03-22 15:33 ` [Qemu-devel] [PATCH 07/12] block: Move actual I/O throttling to BlockBackend Kevin Wolf
2016-03-22 15:33 ` [Qemu-devel] [PATCH 08/12] block: Move I/O throttling configuration functions " Kevin Wolf
2016-03-22 15:33 ` [Qemu-devel] [PATCH 09/12] block: Introduce BdrvChild.opaque Kevin Wolf
2016-03-22 15:33 ` [Qemu-devel] [PATCH 10/12] block: Drain throttling queue with BdrvChild callback Kevin Wolf
2016-03-23 21:29   ` Paolo Bonzini
2016-03-24  8:25     ` Kevin Wolf [this message]
2016-03-24  9:32       ` Paolo Bonzini
2016-03-22 15:33 ` [Qemu-devel] [PATCH 11/12] block: Decouple throttling from BlockDriverState Kevin Wolf
2016-03-22 15:33 ` [Qemu-devel] [PATCH 12/12] block: Don't check throttled reqs in bdrv_requests_pending() Kevin Wolf
2016-03-22 21:33 ` [Qemu-devel] [PATCH 00/12] block: Move I/O throttling to BlockBackend Paolo Bonzini
2016-03-23  9:03   ` Kevin Wolf
2016-03-23  9:28     ` Paolo Bonzini
2016-03-23 10:02       ` Kevin Wolf
2016-03-23 10:05     ` 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=20160324082510.GB4310@noname.redhat.com \
    --to=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).