From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrryW-0007Su-UP for qemu-devel@nongnu.org; Fri, 12 Aug 2011 09:40:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrryV-0007Nj-FB for qemu-devel@nongnu.org; Fri, 12 Aug 2011 09:40:36 -0400 Received: from verein.lst.de ([213.95.11.211]:56245 helo=newverein.lst.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrryV-0007NK-2C for qemu-devel@nongnu.org; Fri, 12 Aug 2011 09:40:35 -0400 Date: Fri, 12 Aug 2011 15:40:33 +0200 From: Christoph Hellwig Message-ID: <20110812134033.GA31736@lst.de> References: <20110811234411.GA19487@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 0/3] better I/O accounting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Christoph Hellwig , qemu-devel@nongnu.org On Fri, Aug 12, 2011 at 06:50:57AM +0100, Stefan Hajnoczi wrote: > I do see the drawbacks of leaving accounting in block.c on every > request. For example, we'll fetch the timestamp for internal requests > as well as external requests from hardware emulation. Due to memory > mapping and bounce buffers it is also possible that requests get > split. Multiwrite also changes the I/O pattern. > > So I guess this external accounting cookie approach is okay. We just > need to be strict about reviewing any code that uses bdrv_aio_*() to > make sure it has accounting in place where appropriate. The most important point is that we potentially have a lot of bdrv_aio_read/write calls for a single guest request. That's the case for both scsi and ide, only virtio does 1 call per guest request (modulo multiwrite).