From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOocn-0000ic-Oy for qemu-devel@nongnu.org; Tue, 02 Sep 2014 10:00:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOoci-0002nF-BZ for qemu-devel@nongnu.org; Tue, 02 Sep 2014 09:59:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44521) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOoci-0002mB-4M for qemu-devel@nongnu.org; Tue, 02 Sep 2014 09:59:52 -0400 From: Markus Armbruster References: <20140828143809.GB28789@irqsave.net> <8761h7fz27.fsf@blackfin.pond.sub.org> <20140901104437.GA15673@irqsave.net> <87bnqzd0vm.fsf@blackfin.pond.sub.org> <20140901133812.GA12307@irqsave.net> Date: Tue, 02 Sep 2014 15:59:45 +0200 In-Reply-To: <20140901133812.GA12307@irqsave.net> (=?utf-8?Q?=22Beno=C3=AE?= =?utf-8?Q?t?= Canet"'s message of "Mon, 1 Sep 2014 15:38:12 +0200") Message-ID: <871trui0mm.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [libvirt] IO accounting overhaul List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?Q?Beno=C3=AEt?= Canet Cc: kwolf@redhat.com, libvir-list@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, anshul.makkar@profitbricks.com Beno=C3=AEt Canet writes: > The Monday 01 Sep 2014 =C3=A0 13:41:01 (+0200), Markus Armbruster wrote : >> Beno=C3=AEt Canet writes: >>=20 >> > The Monday 01 Sep 2014 =C3=A0 11:52:00 (+0200), Markus Armbruster wrot= e : [...] >> >> A quick stab at tasks: >> >>=20 >> >> * QMP interface, either a compatible extension of query-blockstats or= a >> >> new one. >> > >> > I would like to extend query-blockstat in a first time but I also >> > would like to postpone the QMP interface changes and just write the >> > shared infrastructure and deploy it in the device models. >>=20 >> Implementing improved data collection need not wait for the QMP design. >>=20 >> >> * Rough idea on how to do the shared infrastructure. >> > >> > -API wize I think about adding >> > bdrv_acct_invalid() and >> > bdrv_acct_failed() and systematically issuing a bdrv_acct_start() asap. >>=20 >> Complication: partial success. Example: >>=20 >> 1. Guest requests a read of N sectors. >>=20 >> 2. Device model calls >> bdrv_acct_start(s->bs, &req->acct, N * BDRV_SECTOR_SIZE, BDRV_ACCT_RE= AD) >>=20 >> 3. Device model examines the request, and deems it valid. >>=20 >> 4. Device model passes it to the block layer. >>=20 >> 5. Block layer does its thing, but for some reason only M < N sectors >> can be read. Block layer returns M. >>=20 >> 6. What's the device model to do now? Both bdrv_acct_failed() and >> bdrv_acct_done() would be wrong. >>=20 >> Should the device model account for a read of size M? This ignores >> the partial failure. >>=20 >> Should it split the read into a successful and a failed part for >> accounting purposes? This miscounts the number of reads. > > maybe bdrv_acct_partial() accounting the size of data read in the > bandwith counter > and keeping care of counting this event. Two sub-questions: a. What's a convenient interface for device models to report the operation announced with bdrv_acct_start() has succeeded partially? bdrv_acct_partial() sounds okay. Or maybe pass the #bytes actually done to bdrv_acct_done(). Equal to #bytes passed to bdrv_acct_done() means complete sucess, less means partial success. You could even have negative mean complete failure. Could perhaps be more concise. I trust you'll develop a preference while making the device models use your new interface. b. How to count a partially successful operation? In other words, what should your answer to a. do? I guess I'd be fine with simply counting short I/O as if the request had the short size. But if we decide differently, changing the code accordingly should be trivial, so just start with whatever you think is right, and leave the debate (if any) to patch review. > Maybe we will discover some other rare event to account. Yes, but we can worry about it when we run into it. [...]