From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KqolQ-00049Y-PZ
	for qemu-devel@nongnu.org; Fri, 17 Oct 2008 08:49:09 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KqolP-00048c-8W
	for qemu-devel@nongnu.org; Fri, 17 Oct 2008 08:49:08 -0400
Received: from [199.232.76.173] (port=46049 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KqolO-00048O-Gd
	for qemu-devel@nongnu.org; Fri, 17 Oct 2008 08:49:06 -0400
Received: from mx2.redhat.com ([66.187.237.31]:52533)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1KqolM-00009v-LM
	for qemu-devel@nongnu.org; Fri, 17 Oct 2008 08:49:05 -0400
Message-ID: <48F88992.8040803@redhat.com>
Date: Fri, 17 Oct 2008 14:48:18 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [RFC] Disk integrity in QEMU
References: <48EE38B9.2050106@codemonkey.ws>	<20081013170610.GF21410@us.ibm.com>	<6A99DBA5-D422-447D-BF9D-019FB394E6C6@lvivier.info>	<20081013194328.GJ21410@us.ibm.com>	<148FE536-F397-4F51-AE3F-C94E4F1F5D4E@lvivier.info>	<20081013210509.GL21410@us.ibm.com>	<1224076205.4150.17.camel@frecb07144>	<1224152681.4168.5.camel@frecb07144>
	<48F74511.8080700@codemonkey.ws>
In-Reply-To: <48F74511.8080700@codemonkey.ws>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Chris Wright <chrisw@redhat.com>, Mark McLoughlin <markmc@redhat.com>, Ryan Harper <ryanh@us.ibm.com>

Anthony Liguori wrote:
>>
>>                  | total time | per-request stat (ms) |
>>                  |  (seconds) |  min  |  avg  |  max  |
>> -----------------+------------+-------+-------+-------+
>> baremetal        |   208.6237 |   2.5 |  16.7 | 942.6 |
>> -----------------+------------+-------+-------+-------+
>> cache=on         |   642.2962 |   2.5 |  51.4 | 326.9 |
>> -----------------+------------+-------+-------+-------+
>> cache=on,O_DSYNC |   646.6570 |   2.7 |  51.7 | 347.0 |
>> -----------------+------------+-------+-------+-------+
>> cache=off        |   635.4424 |   2.9 |  50.8 | 399.5 |
>> -----------------+------------+-------+-------+-------+
>>   
>
> Because you're talking about 1/3% of native performance.  This means
> that you may be dominated by things like CPU overhead verses actual IO
> throughput.

I don't know mysql well, but perhaps it sizes its internal cache to
system memory size, so baremetal has 4x the amount of cache.

If mysql uses mmap to access its data files, then it automatically
scales with system memory.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.