From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWM6h-0001ab-JM for qemu-devel@nongnu.org; Tue, 23 Sep 2014 05:10:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWM6X-0004MX-Gy for qemu-devel@nongnu.org; Tue, 23 Sep 2014 05:09:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWM6X-0004Ll-94 for qemu-devel@nongnu.org; Tue, 23 Sep 2014 05:09:49 -0400 Date: Tue, 23 Sep 2014 11:09:19 +0200 From: Kevin Wolf Message-ID: <20140923090919.GC3871@noname.str.redhat.com> References: <1409935888-18552-3-git-send-email-pl@kamp.de> <20140908134434.GB22582@irqsave.net> <540DB3E2.6010905@redhat.com> <540DB583.4030101@kamp.de> <540DB5EB.2070705@redhat.com> <540DBEBD.9040701@kamp.de> <540DC059.4000907@redhat.com> <540DC30B.2040408@kamp.de> <20140923084758.GA3871@noname.str.redhat.com> <5421356C.3030108@kamp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5421356C.3030108@kamp.de> Subject: Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , stefanha@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, ronniesahlberg@gmail.com, Paolo Bonzini Am 23.09.2014 um 10:55 hat Peter Lieven geschrieben: > >> - should we only merge requests within the same cluster? > >Does it hurt to merge everything we can? The block driver needs to be > >able to take things apart anyway, the large request could come from > >somewhere else (guest, block job, builtin NBD server, etc.) > > I was just thinking. It was unclear what the original intention was. I hope it's clearer now. Anyway, for qcow2 merging even across clusters does help a bit if those clusters are physically contiguous. > My concern was that merging too much will increase latency for > the specific I/O even if it increases throughput. That's probably a valid concern. Perhaps we should add a set of options to enable or disable certain request manipulations that the block layer can do. This includes request merging, but also alignment adjustments, zero detection (which already has an option) etc. > >> - why is there no multiread_merge? > >Because nobody implemented it. :-) > > Maybe its worth looking at this. Taking the multiwrite_merge stuff as > a basis it shouldn't be too hard. Yes, it should be doable. We need numbers, though, before merging something like this. > >As I said above, writes hurt a lot because of qcow2 cluster allocation. > >Reads are probably losing some performance as well (someone would need > >to check this), but processing them separately isn't quite as painful. > > I will try to sort that out. Great, thanks! Kevin