From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MikGa-00084E-Bl for qemu-devel@nongnu.org; Wed, 02 Sep 2009 03:28:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MikGV-00083V-R7 for qemu-devel@nongnu.org; Wed, 02 Sep 2009 03:28:27 -0400 Received: from [199.232.76.173] (port=50625 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MikGV-00083S-Jx for qemu-devel@nongnu.org; Wed, 02 Sep 2009 03:28:23 -0400 Received: from mx20.gnu.org ([199.232.41.8]:10069) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MikGU-000075-W7 for qemu-devel@nongnu.org; Wed, 02 Sep 2009 03:28:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MikGU-0003N1-5y for qemu-devel@nongnu.org; Wed, 02 Sep 2009 03:28:22 -0400 Message-ID: <4A9E1E4F.4080901@redhat.com> Date: Wed, 02 Sep 2009 09:27:11 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/3] block: Handle multiple write requests at once References: <1251813112-17408-1-git-send-email-kwolf@redhat.com> <20090901155228.GA21781@lst.de> In-Reply-To: <20090901155228.GA21781@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: qemu-devel@nongnu.org Christoph Hellwig schrieb: > On Tue, Sep 01, 2009 at 03:51:49PM +0200, Kevin Wolf wrote: >> virtio often issues multiple requests in a row, but each one independently. If >> the block drivers knew all of the requests, they could optimize the way they >> handle the requests. See the description of patch 3 for how qcow2 can use this >> to avoid unnecessary writes to the disk. > > I think this interface is extremly awkward and the layering is wrong. > Everyone benefits from having one large instead of multiple small > requests, so if we do get multiple sequential write requests we should > always merged it at a high level even before starting to issue AIO, > e.g. do it all in virtio-blk. While I don't agree with everything you're saying, I think you do have a point. When you're working on one specific problem, you're sometimes blind for the big picture. It's true that the functionality that is implemented so far could be useful for all block formats. I'm not sure if merging requests is the only useful thing you could with it, but for now it seems to be the only one. So the general merging mechanism doesn't belong into the qcow2 block driver. On the other hand, if you look at the TODO which says that we need to merge requests if they are not directly adjacent, but touch the same cluster, this is something that cannot be done by the generic block layer - it doesn't even know that things like clusters exist. We could have a block driver function like bdrv_can_merge that takes two requests and checks if it would make sense to merge these requests. Does that make sense? Your suggestion to do it all in virtio-blk I don't like at all. We need to do it in the most generic place, not in earliest possible place. Why shouldn't there be other devices that could profit from it? Not sure about IDE and SCSI, but the Xen disk device should definitely be able to make use of it. Let's not make the mistake to change the code from being too format specific to being too device specific. It belongs in block.c. > Of course using a sane filesystem in the guest would also fix it, > but the point of virtualization is at least partially to keep all > that old crap working nicely. Not sure what your definition of "old crap" is, but ext3 seems to meet it. I don't think it's irrelevant. Kevin