From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KrvXZ-0002En-RJ
	for qemu-devel@nongnu.org; Mon, 20 Oct 2008 10:15:25 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KrvXX-0002Ck-St
	for qemu-devel@nongnu.org; Mon, 20 Oct 2008 10:15:24 -0400
Received: from [199.232.76.173] (port=37554 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KrvXV-0002CV-Qv
	for qemu-devel@nongnu.org; Mon, 20 Oct 2008 10:15:21 -0400
Received: from mx2.redhat.com ([66.187.237.31]:43922)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1KrvXV-0000xJ-18
	for qemu-devel@nongnu.org; Mon, 20 Oct 2008 10:15:21 -0400
Message-ID: <48FC9252.7070803@redhat.com>
Date: Mon, 20 Oct 2008 16:14:42 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
References: <48EF1D55.7060307@redhat.com> <48F0E83E.2000907@redhat.com>
	<48F10DFD.40505@codemonkey.ws> <48F1CD76.2000203@redhat.com>
	<20081017132040.GK19428@kernel.dk> <48FAF751.8010806@redhat.com>
	<20081019181026.GU19428@kernel.dk> <48FB7B7A.4050008@redhat.com>
	<20081019183642.GV19428@kernel.dk> <48FB865B.60906@redhat.com>
	<20081019193024.GX19428@kernel.dk>
In-Reply-To: <20081019193024.GX19428@kernel.dk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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: Jens Axboe <qemu@kernel.dk>
Cc: Chris Wright <chrisw@redhat.com>, Mark McLoughlin <markmc@redhat.com>, kvm-devel <kvm-devel@lists.sourceforge.net>, Laurent Vivier <Laurent.Vivier@bull.net>, qemu-devel@nongnu.org, Ryan Harper <ryanh@us.ibm.com>

Jens Axboe wrote:
> Use hdparm, it's an ATA drive even if Linux currently uses the scsi
> layer for it. Or use sysfs, there's a "cache_type" attribute in the scsi
> disk sysfs directory.
>   

With this, I was able to benchmark the write cache for 4k and 128k 
random access loads.  Numbers in iops, hope it doesn't get mangled:


                4k blocks            128k blocks
pattern   cache off   cache on  cache off   cache on
read       103         101         74         71
write       86         149         72         91
rw          87          89         63         65

Test was run on a 90G logical volume of a 250G laptop disk; using 
O_DIRECT and libaio.

Pure write workloads see a tremendous benefit, likely because the heads 
can do a linear scan of the disk.  An 8MB cache translates to 2000 
objects, likely around 1000 per pass.  Increasing the block size reduces 
the performance boost, as expected.

read/write workloads do not benefit at all (or maybe a bit); presumably 
the head movement is governed by reads alone.

Of course, this tests only the disk subsystem; in particular, if some 
workload is sensitive to write latencies, the write cache can reduce 
those in a mixed read/write load, as long as the cache is not flooded 
(so loads with a lower percentage of writes would benefit more).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.