[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 10/12] block: Drain throttling queue with BdrvCh
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH 10/12] block: Drain throttling queue with BdrvChild callback |
Date: |
Thu, 24 Mar 2016 09:25:10 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- Re: [Qemu-devel] [PATCH 03/12] block: Introduce BlockBackendPublic, (continued)
[Qemu-devel] [PATCH 04/12] block: throttle-groups: Use BlockBackend pointers internally, Kevin Wolf, 2016/03/22
[Qemu-devel] [PATCH 08/12] block: Move I/O throttling configuration functions to BlockBackend, Kevin Wolf, 2016/03/22
[Qemu-devel] [PATCH 11/12] block: Decouple throttling from BlockDriverState, Kevin Wolf, 2016/03/22
[Qemu-devel] [PATCH 05/12] block: Convert throttle_group_get_name() to BlockBackend, Kevin Wolf, 2016/03/22
[Qemu-devel] [PATCH 07/12] block: Move actual I/O throttling to BlockBackend, Kevin Wolf, 2016/03/22
[Qemu-devel] [PATCH 10/12] block: Drain throttling queue with BdrvChild callback, Kevin Wolf, 2016/03/22
[Qemu-devel] [PATCH 06/12] block: Move throttling fields from BDS to BB, Kevin Wolf, 2016/03/22
[Qemu-devel] [PATCH 12/12] block: Don't check throttled reqs in bdrv_requests_pending(), Kevin Wolf, 2016/03/22
Re: [Qemu-devel] [PATCH 00/12] block: Move I/O throttling to BlockBackend, Paolo Bonzini, 2016/03/22