From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj0Zy-0006yS-9c for qemu-devel@nongnu.org; Thu, 24 Mar 2016 04:25:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj0Zx-0000PB-Av for qemu-devel@nongnu.org; Thu, 24 Mar 2016 04:25:18 -0400 Date: Thu, 24 Mar 2016 09:25:10 +0100 From: Kevin Wolf Message-ID: <20160324082510.GB4310@noname.redhat.com> References: <1458660792-3035-1-git-send-email-kwolf@redhat.com> <1458660792-3035-11-git-send-email-kwolf@redhat.com> <56F30A9F.6040300@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F30A9F.6040300@redhat.com> Subject: Re: [Qemu-devel] [PATCH 10/12] block: Drain throttling queue with BdrvChild callback List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org 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