From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMfpx-0002ZF-I4 for qemu-devel@nongnu.org; Thu, 19 Sep 2013 11:08:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMfpp-00032Y-Oi for qemu-devel@nongnu.org; Thu, 19 Sep 2013 11:08:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMfpp-00032Q-GX for qemu-devel@nongnu.org; Thu, 19 Sep 2013 11:08:01 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8JF80ga013976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Sep 2013 11:08:00 -0400 Message-ID: <523B134C.8060902@redhat.com> Date: Thu, 19 Sep 2013 17:07:56 +0200 From: Max Reitz MIME-Version: 1.0 References: <1378106712-29856-1-git-send-email-mreitz@redhat.com> In-Reply-To: <1378106712-29856-1-git-send-email-mreitz@redhat.com> Content-Type: multipart/mixed; boundary="------------060708020308000809080904" Subject: Re: [Qemu-devel] [PATCH v5 0/8] Add metadata overlap checks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi This is a multi-part message in MIME format. --------------060708020308000809080904 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id r8JF80ga013976 Hi, I've done some benchmarks regarding this series now. In particular, I've=20 created a 7G image, installed Arch Linux to a partition in the first 2G=20 and created an empty ext4 partition for benchmarking in the remaining 5G. My first test consisted of running bonnie++ ("bonnie++ -d [scratch=20 partition] -s 4g -n 0 -x 16 -Z /dev/urandom" (4G files for I/O=20 performance tests, no file creation tests, repeat 16 times)) using=20 different metadata overlap checks (none, constant (all tests can be=20 performed in constant time) and cached (current default)). The reason I=20 didn't test for "all" (perform all overlap checks) is that this will=20 only make a difference (when compared to "cached") if there are=20 snapshots (right now, at least). I put the underlying image file to /tmp=20 (tmpfs) for minimal true I/O latency (to maximize the check overhead). The second test was basically the same, except I've taken 100 (internal)=20 snapshots before and used 2G files instead of 4G. In this case, I also=20 tested the "all" scenario. I performed the third test on a HDD instead of tmpfs to maximize the=20 overhead of non-cached overlap checks (that is, checking inactive L2=20 table overlaps right now) which require disk I/O. I used -drive=20 cache=3Dnone for this test (in contrast to the others which ran on a tmpf= s=20 anyway). Also, I've used 256M files since 2G just took too much time. :) As far as I understand, the I/O speed (the duration of an I/O operation)=20 should be pretty much the same for all scenarios, however, the latency=20 is the value in question (since the overlap checks should affect the=20 latency only). Basically, I didn't get any results which indicate a performance hit.=20 The raw HDD test data sometimes resulted in a standard deviation greater=20 than the average itself (!), thus I've removed some outliers there. The=20 averages rarely exceed each other's standard deviation and if they do,=20 often there is no trend at all. The only time there is a real trend=20 exceeding the standard deviation is for block writes in my first test =E2= =80=93=20 however, the trend is negative, indicating overlap checks actually sped=20 things up (which is obviously contraintuitive). The difference, however,=20 is below 1 % anyway. The only major differences visible (exceeding the combined standard=20 deviation of the two values in question) occured during the HDD test:=20 The duration of putc, block writes and rewrites for HDDs was much=20 greater (about 10 to 20 %, however, bear in mind the standard deviation=20 is in that magnitude as well) for "constant" and "cached" than for=20 "none" and "all". On the other hand, the putc and rewrite latency was=20 much better for "constant" and "cached" then for "none" and "all". The=20 durations differing so greatly is a sign to me that the data from this=20 test is not really usable (since I think it should be the same for all=20 scenarios). If we're to ignore that and the fact that there was indeed a=20 higher latency in "none" than in "all" for both latencies affected, we=20 could conclude that "all" is really much slower than "constant" or=20 "cached". But then again, the block write latency was even smaller for=20 "all" than for "cached" and "constant", so I'd just ignore these=20 benchmarks (for the HDD). All in all, I don't see any significant performance difference when=20 benchmarking on a tmpfs (which should maximize the overhead of=20 "constant" and "cached") and the data from my HDD benchmarks is probably=20 stastically unusable. The only comparison which they would have been=20 useful for are the comparison of "all" to "cached", but since "all" will=20 not be the default (and anyone explicitly using this option is in fact=20 responsible for slow I/O himself)) they aren't actually that important=20 anyway. I've attached a CSV file containing the edited results, that is, the=20 averages and standard deviations for the tests performed by bonnie++,=20 excluding some outliers from the HDD benchmark; I think the values are=20 given in microseconds. Max --------------060708020308000809080904 Content-Type: text/csv; name="res.csv" Content-Disposition: attachment; filename="res.csv" Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by mx1.redhat.com id r8JF80ga013976 LHB1dGMscHV0X2Jsb2NrLHJld3JpdGUscHV0Y19sYXRlbmN5LHB1dF9ibG9ja19sYXRlbmN5 LHJld3JpdGVfbGF0ZW5jeQ0KdG1wZnMgKDRHKSwsLCwsLA0KTm9uZSwxMzc2wrExMiwxMTEy NjU4wrE0MjMwLDQ2MzUwN8KxMzc3NzcsOTkzNMKxMTAyMSw2NzQwwrExNDQsMzMxNDPCsTcw NDMNCkNvbnN0YW50LDEzMzjCsTgsMTEwNzAyNMKxMjM0Nyw0NzY4MzHCsTM1ODYwLDEwMDE0 wrExMDkwLDY4NDbCsTI1NCwzNDExNcKxNTg2Nw0KQ2FjaGVkLDEzNjbCsTksMTEwNDk4MMKx MzkwMyw0NjMwNznCsTM5MTY0LDEwNDEzwrExMTU4LDY3OTTCsTE4MSwzMzgyMMKxNjMzOA0K dG1wZnMrc25hcHNob3RzICgyRyksLCwsLCwNCk5vbmUsMTM5MsKxOCwxMTI3ODAywrE2MTMx LDQ1OTcxMsKxMjQ5NjAsOTYxNMKxMTEzMiw2NTIzwrExMjAsMjc4MjPCsTYxNDINCkNvbnN0 YW50LDEzOTbCsTExLDExMjYyMDbCsTQyMjQsNDUzMjYwwrEyNTEzNSw5MTc4wrExMjQ5LDY1 NznCsTEyNiwyMzIyMcKxNzUyMQ0KQ2FjaGVkLDEzOTTCsTcsMTExOTY5OcKxNjI3Niw0Njc2 MjfCsTI3Nzg0LDk0NzDCsTk1MSw2NjE2wrExMzcsMjcyNTTCsTY3ODUNCkFsbCwxMzk4wrEx MiwxMTIzMjQ1wrEzODA1LDQ3Mjg1MMKxMjk4MzYsOTUwMMKxODIzLDY2MTfCsTE2OSwyODU1 NcKxNjIwNg0KSEREK3NuYXBzaG90cyAoMjU2TSksLCwsLCwNCk5vbmUsODUwwrEyMSw3Mjg2 MsKxOTc2NSwzMjM5MsKxMzkwMCwxNTk1NMKxMTk0MiwxMjYyMjbCsTI4NzMzLDE0ODkyOcKx Mzc0ODMNCkNvbnN0YW50LDk4NsKxMTcsODQyNDDCsTkwMDksMzgyNDfCsTExMTcsMTA4NDPC sTEyMTQsMTAxNDk2wrEyOTk5NywxMDY2MjfCsTE5MDk4DQpDYWNoZWQsOTg4wrExOSw4NDEx McKxODQ2MCwzNzY5McKxMTM3OSwxMDMxMMKxNzYxLDEwMTI0OcKxNDIzNjYsMTAzOTUwwrEx NDQ1Mw0KQWxsLDg3M8KxMTMsNzUzOTLCsTU1MDYsMzQ1NTbCsTEyNzMsMTI2OTDCsTU2Myw5 NTUwNsKxNDkxNywxMzQyMjDCsTI0MjU2DQo= --------------060708020308000809080904--