From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1G8H-0003Qh-0g for qemu-devel@nongnu.org; Wed, 17 Dec 2014 10:03:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1G87-0007fq-EJ for qemu-devel@nongnu.org; Wed, 17 Dec 2014 10:03:20 -0500 Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:39321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1G87-0007fk-8L for qemu-devel@nongnu.org; Wed, 17 Dec 2014 10:03:11 -0500 Received: by mail-wi0-f180.google.com with SMTP id n3so16421291wiv.1 for ; Wed, 17 Dec 2014 07:03:10 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54919B29.4080009@redhat.com> Date: Wed, 17 Dec 2014 16:03:05 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1418305950-30924-1-git-send-email-pbonzini@redhat.com> <1418305950-30924-2-git-send-email-pbonzini@redhat.com> <20141216110727.GA27195@noname.str.redhat.com> <54901764.6050307@redhat.com> <20141216131034.GA3301@noname.str.redhat.com> <549079CC.4010109@redhat.com> <5490958E.8030803@redhat.com> <54917852.2060201@redhat.com> In-Reply-To: <54917852.2060201@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2 1/5] linux-aio: queue requests that cannot be submitted List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: ming.lei@canonical.com, pl@kamp.de, qemu-devel@nongnu.org, stefanha@redhat.com On 17/12/2014 13:34, Paolo Bonzini wrote: > > > On 16/12/2014 21:26, Paolo Bonzini wrote: >> >>> I could reproduce this very well on a random OS image that I had around. >>> This is raw over XFS over dm-crypt, and the image is about 75% sparse >>> (8.2G used over 35G). I only get 1-2%, but still it's visible. >>> >>> However I can hardly reproduce it when using a partition directly: >>> >>> old new >>> mean 9.9565 9.9636 (+0.07%) >>> stddev 0.0405 0.0537 >>> min 9.871 9.867 >>> median 9.973 9.971 >>> max 10.01 10.053 >>> count 20 20 >>> >>> I haven't tried removing layers (e.g. fully-allocated XFS image without >>> dm-crypt). >> >> Could not reproduce it with a fully-allocated XFS image, on the contrary >> the patched QEMU is a bit faster: >> >> old new >> mean 14.83325 14.82660 >> stddev 0.016930 0.010328 >> min 14.819 14.818 >> max 14.854 14.883 >> median 14.8225 14.8255 >> count 20 20 > > Same for 50% sparse XFS image, patched QEMU a bit faster: > > old new > Mean 8.31285 8.30625 > stddev 0.03690 0.03333 > min 8.277 8.276 > max 8.378 8.382 > median 8.292 8.2905 > count 20 20 Today I cannot reproduce it even on the original testcase: old new mean 9.64175 9.60935 stddev 0.15211 0.11117 min 9.445 9.454 max 10.102 9.835 median 9.64 9.6205 count 20 20 Some notes: 1) do you have Fam's io_get_events patch? I don't, and the tests probably should be done with it. 2) "qemu-img bench" probably could also be changed to use AioContext directly instead of going through GMainLoop. That said, there is some low-hanging fruit for GMainLoop that I'll shortly send a patch for. 3) bench_cb does this: b->sector += b->bufsize; Should it shift right by >> BDRV_SECTOR_BITS? Or is it intended to do the equivalent of a random read benchmark? Paolo