From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43996 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHIiw-0004Ui-QE for qemu-devel@nongnu.org; Wed, 26 May 2010 11:40:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHIiv-0007aC-F7 for qemu-devel@nongnu.org; Wed, 26 May 2010 11:40:50 -0400 Received: from hall.aurel32.net ([88.191.82.174]:56764) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHIiv-0007Zx-8f for qemu-devel@nongnu.org; Wed, 26 May 2010 11:40:49 -0400 Message-ID: <4BFD40F3.7020406@aurel32.net> Date: Wed, 26 May 2010 17:40:35 +0200 From: Aurelien Jarno MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Add cache=volatile parameter to -drive References: <1274091292-4812-1-git-send-email-agraf@suse.de> <4BF14CE9.5040907@suse.de> <4BF15DC8.8080104@codemonkey.ws> <201005171723.15675.paul@codesourcery.com> <4BF16E22.6090400@codemonkey.ws> <4BFC0FF6.1080005@suse.de> <20100525210113.GE1402@hall.aurel32.net> <4BFC79E8.1070700@codemonkey.ws> <20100526085248.GC21913@volta.aurel32.net> <4BFD269E.9090503@codemonkey.ws> <4BFD2C57.4050606@aurel32.net> <4BFD2DF7.6020806@codemonkey.ws> In-Reply-To: <4BFD2DF7.6020806@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kwolf@redhat.com, Paul Brook , qemu-devel@nongnu.org, Alexander Graf , hch@lst.de Anthony Liguori a écrit : > On 05/26/2010 09:12 AM, Aurelien Jarno wrote: >>> It's hard for me to consider this a performance regression because >>> ultimately, you're getting greater than bare metal performance (because >>> of extremely aggressive caching). It might be a regression from the >>> previous performance, but that was at the cost of safety. >>> >> For people who don't care about safety it's still a regression. And it >> is a common usage of QEMU. >> > > It's not a functional change. It's a change in performance. There are > tons of changes in performance characteristics of qemu from version to > version. It's not even a massive one. > >>> We might get 100 bug reports about this "regression" but they concern >>> much less than 1 bug report of image corruption because of power >>> failure/host crash. A reputation of being unsafe is very difficult to >>> get rid of and is something that I hear concerns about frequently. >>> >>> I'm not suggesting that the compile option should be disabled by default >>> upstream. But the option should be there for distributions because I >>> hope that any enterprise distro disables it. >>> >>> >> Which basically means those distro don't care about some use cases of >> QEMU, that were for most of them the original uses cases. It's sad. >> > > This isn't a feature. This is a change in performance. No one is not > able to satisfy their use case from this behavior. > >> Sometimes I really whishes that KVM never tried to reintegrate code into >> QEMU, it doesn't bring only good things. >> > > I highly doubt that this is even visible on benchmarks without using > KVM. The improvement on a microbenchmark was relatively small and the > cost from TCG would almost certainly dwarf it. It is something clearly visible. Before fsync() was not used, and it happens this syscall can be very expensive (ie a few seconds, especially with some other i/o load on the system) on ext3 with not so old kernels. A google search for "firefox fsync" will give you a few pointers. > Also, remember before KVM, we had single threaded IO and posix-aio > (which is still single threaded). If KVM never happened, block > performance would be far, far worse than it is today with cache=writeback. > io thread is not enable by default in QEMU. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net