From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1YQD-0002BM-Js for qemu-devel@nongnu.org; Thu, 18 Dec 2014 05:35:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1YQ7-000310-FA for qemu-devel@nongnu.org; Thu, 18 Dec 2014 05:35:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1YQ7-00030Y-6h for qemu-devel@nongnu.org; Thu, 18 Dec 2014 05:34:59 -0500 Date: Thu, 18 Dec 2014 11:34:45 +0100 From: Kevin Wolf Message-ID: <20141218103445.GA25902@noname.redhat.com> References: <1418743287-20467-1-git-send-email-pl@kamp.de> <20141216154832.GB3301@noname.str.redhat.com> <5490571B.8070207@kamp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5490571B.8070207@kamp.de> Subject: Re: [Qemu-devel] [PATCH V2 0/4] *virtio-blk: add multiread support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: famz@redhat.com, benoit@irqsave.net, ming.lei@canonical.com, armbru@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com, mreitz@redhat.com Am 16.12.2014 um 17:00 hat Peter Lieven geschrieben: > On 16.12.2014 16:48, Kevin Wolf wrote: > >Am 16.12.2014 um 16:21 hat Peter Lieven geschrieben: > >>this series adds the long missing multiread support to virtio-blk. > >> > >>some remarks: > >> - i introduced rd_merged and wr_merged block accounting stats to > >> blockstats as a generic interface which can be set from any > >> driver that will introduce multirequest merging in the future. > >> - the knob to disable request merging is not yet there. I would > >> add it to the device properties also as a generic interface > >> to have the same switch for any driver that might introduce > >> request merging in the future. As there has been no knob in > >> the past I would post this as a seperate series as it needs > >> some mangling in parameter parsing which might lead to further > >> discussions. > >> - the old multiwrite interface is still there and might be removed. > >> > >>v1->v2: > >> - add overflow checking for nb_sectors [Kevin] > >> - do not change the name of the macro of max mergable requests. [Fam] > >Diff to v1 looks good. Now I just need to check what it does to the > >performance. Did you run any benchmarks yourself? > > I ran several installs of Debian/Ubuntu, Booting of Windows and Linux > systems. I looked at rd_total_time_ns and wr_total_time_ns and saw > no increase. Ofter I even saw even a decrease. > > {rd,wr}_total_time_ns measures the time from virtio_blk_handle_request > to virtio_blk_rw_complete. So it seems to be a good indicator for the time > spent with I/O. > > What you could to is post it on the top of your fio testing stack and > look at the throughput. Sequential Reads should be faster. The rest > not worse. So I finally ran some fio benchmark on the series. The result for small sequential reads (4k) is quite noisy, but it seems to be improved a bit. Larger sequenial reads (64k) and random reads seem to be mostly unaffected. For writes, however, I can see a degradation. Perhaps running multiple jobs in parallel means that we don't detect and merge sequential requests any more when they are interleaved with another sequential job. Or do you have an idea what else could have changed for writes? Kevin