From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mipf2-00075A-V5 for qemu-devel@nongnu.org; Wed, 02 Sep 2009 09:14:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mipey-00073e-OU for qemu-devel@nongnu.org; Wed, 02 Sep 2009 09:14:04 -0400 Received: from [199.232.76.173] (port=47184 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mipey-00073Y-GQ for qemu-devel@nongnu.org; Wed, 02 Sep 2009 09:14:00 -0400 Received: from fg-out-1718.google.com ([72.14.220.154]:55652) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mipey-0006E3-5k for qemu-devel@nongnu.org; Wed, 02 Sep 2009 09:14:00 -0400 Received: by fg-out-1718.google.com with SMTP id e21so1026193fga.10 for ; Wed, 02 Sep 2009 06:13:59 -0700 (PDT) Message-ID: <4A9E6F90.8060609@codemonkey.ws> Date: Wed, 02 Sep 2009 08:13:52 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/4] block: add enable_write_cache flag References: <20090831201627.GA4811@lst.de> <20090831201651.GA4874@lst.de> <20090831220950.GB24318@shareable.org> <20090831221622.GA8834@lst.de> <4A9C5463.4090904@codemonkey.ws> <20090902035337.GA18844@lst.de> In-Reply-To: <20090902035337.GA18844@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: qemu-devel@nongnu.org Christoph Hellwig wrote: > On Mon, Aug 31, 2009 at 05:53:23PM -0500, Anthony Liguori wrote: > >> I think we should pity our poor users and avoid adding yet another >> obscure option that is likely to be misunderstood. >> >> Can someone do some benchmarking with cache=writeback and fdatasync >> first and quantify what the real performance impact is? >> > > Some preliminary numbers because they are very interesting. Note that > his is on a raid controller, not cheap ide disks. To make up for that > I used an image file on ext3, which due to it's horrible fsync > performance should be kind of a worst case. All these patches are > with Linux 2.6.31-rc8 + my various barrier fixes on guest and host, > using ext3 with barrier=1 on both. > Does barrier=0 make a performance difference? IOW, would the typical default ext3 deployment show worse behavior? > A kernel defconfig compile takes between 9m40s and 9m42s with > data=writeback and barrieres disabled, and with fdatasync barriers > enabled it actually is minimally faster, If fdatasync different than fsync on ext3? Does it result in a full metadata commit? If we think these numbers make sense, then I'd vote for enabling fdatasync in master and we'll see if there are any corner cases. > between 9m38s and 9m39s > (given that I've only done three runs each this might fall under > the boundary for measurement tolerances). > > For comparism the raw block device nodes with cache=none (just one run) > is 9m36.759s, which is not far apart. A completely native run is > 7m39.326, btw - and I fear much of the slowdown in KVM isn't I/O > related. > If you're on pre-NHM or BCN then the slowdown from shadow paging would be expected. Regards, Anthony Liguori