From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50298 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHHSP-00050J-DZ for qemu-devel@nongnu.org; Wed, 26 May 2010 10:19:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHHSO-0006Ls-B7 for qemu-devel@nongnu.org; Wed, 26 May 2010 10:19:41 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:47949) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHHSO-0006Lb-5f for qemu-devel@nongnu.org; Wed, 26 May 2010 10:19:40 -0400 Received: by gyd5 with SMTP id 5so3016537gyd.4 for ; Wed, 26 May 2010 07:19:39 -0700 (PDT) Message-ID: <4BFD2DF7.6020806@codemonkey.ws> Date: Wed, 26 May 2010 09:19:35 -0500 From: Anthony Liguori 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> In-Reply-To: <4BFD2C57.4050606@aurel32.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: kwolf@redhat.com, Alexander Graf , hch@lst.de, Paul Brook , qemu-devel@nongnu.org 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. 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. Regards, Anthony Liguori