From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxwBq-0003Qo-BV for qemu-devel@nongnu.org; Thu, 28 May 2015 07:41:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxwBl-0000Ll-Av for qemu-devel@nongnu.org; Thu, 28 May 2015 07:41:34 -0400 Message-ID: <5566FED5.2040901@redhat.com> Date: Thu, 28 May 2015 13:41:09 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20150526142210.GI24077@noname.str.redhat.com> <55648220.1030206@redhat.com> <20150527090745.GA4669@noname.str.redhat.com> <55659372.9060804@redhat.com> <20150527101016.GB4669@noname.str.redhat.com> <55659FCC.2030704@redhat.com> <20150528024950.GC22609@dhcp-14-238.nay.redhat.com> <20150528094047.GB3385@noname.redhat.com> <20150528105538.GB8461@dhcp-14-238.nay.redhat.com> <5566F545.9070303@redhat.com> <20150528112439.GD3385@noname.redhat.com> In-Reply-To: <20150528112439.GD3385@noname.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 01/13] block: Add op blocker type "device IO" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Fam Zheng , qemu-block@nongnu.org, qemu-devel@nongnu.org, jcody@redhat.com, armbru@redhat.com, Max Reitz , Stefan Hajnoczi , amit.shah@redhat.com On 28/05/2015 13:24, Kevin Wolf wrote: > Am 28.05.2015 um 13:00 hat Paolo Bonzini geschrieben: >> On 28/05/2015 12:55, Fam Zheng wrote: >>>> Indeed. blk_pause/resume would handle everything in one central place >>>> in the block layer instead of spreading the logic across all the block >>>> layer users. >>> >>> Sorry, I'm confused. Do you mean there is a way to implement blk_pause >>> completely in block layer, without the necessity of various notifier handlers >>> in device models? >> >> How would you do that? Do you have to keep a queue of pending requests >> in the BlockBackend? Since bdrv_drain_all may never return (e.g. stuck >> NFS connection with nfs=hard), the guest can force unbounded allocation >> in the host, which is bad. > > We already queue requests for things like I/O throttling or > serialisation. Why would this be any worse? The fact that it's potentially unbounded makes me nervous. But you're right that we sort of expect the guest to not have too high a queue depth. And serialization is also potentially unbounded. So it may indeed be the best way. Just to double check, is it correct that the API would still be BDS-based, i.e. bdrv_pause_backends/bdrv_resume_backends, and the BlockBackends would attach themselves to pause/resume notifier lists? Paolo >> In addition, the BDS doesn't have a list of BlockBackends attached to >> it. So you need the BlockBackends to register themselves for >> pause/resume in some way---for example with a notifier list. >> >> Then it's irrelevant whether it's the device model or the BB that >> attaches itself to the notifier list. You can start with doing it in >> the device models (those that use ioeventfd), and later it can be moved >> to the BB. The low-level implementation remains the same. > > The reason for doing it in the block layer is that it's in one place and > we can be sure that it's applied. We can still in addition modify > specific users to avoid even trying to send requests, but I think it's > good to have the single place that always ensures correct functionality > of the drain instead of making it dependent on the user. > > Kevin >