From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kp8EL-0003b3-Kb for qemu-devel@nongnu.org; Sun, 12 Oct 2008 17:12:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kp8EJ-0003ZO-Fz for qemu-devel@nongnu.org; Sun, 12 Oct 2008 17:12:00 -0400 Received: from [199.232.76.173] (port=35219 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kp8EJ-0003ZH-9h for qemu-devel@nongnu.org; Sun, 12 Oct 2008 17:11:59 -0400 Received: from mail-gx0-f19.google.com ([209.85.217.19]:49251) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kp8EJ-0006vd-7j for qemu-devel@nongnu.org; Sun, 12 Oct 2008 17:11:59 -0400 Received: by gxk12 with SMTP id 12so2778394gxk.10 for ; Sun, 12 Oct 2008 14:11:57 -0700 (PDT) Message-ID: <48F2681A.1030401@codemonkey.ws> Date: Sun, 12 Oct 2008 16:11:54 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU References: <48EE38B9.2050106@codemonkey.ws> <48EF1D55.7060307@redhat.com> <48F0E83E.2000907@redhat.com> <48F10DFD.40505@codemonkey.ws> <20081012004401.GA9763@acer.localdomain> <48F1CF9E.9030500@redhat.com> <48F23AF1.2000104@codemonkey.ws> <48F24320.9010201@redhat.com> <48F25720.9010306@codemonkey.ws> <48F26171.70109@redhat.com> In-Reply-To: <48F26171.70109@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Chris Wright , Mark McLoughlin , kvm-devel , Laurent Vivier , qemu-devel@nongnu.org, Ryan Harper Avi Kivity wrote: > Given that we don't have a zero-copy implementation yet, it is > impossible to generate real performance data. Which means that it's premature to suggest switching the default to O_DIRECT since it's not going to help right now. It can be revisited once we can do zero copy but again, I think it should be driven by actual performance data. My main point is that switching to O_DIRECT right now is only going to hurt performance for some users, and most likely help no one. > Now I don't have data that demonstrates how bad these effects are, but I > think there is sufficient arguments here to justify adding O_DIRECT. I > intend to recommend O_DIRECT unless I see performance data that favours > O_DSYNC on real world scenarios that take into account bandwidth, cpu > utilization, and memory utilization (i.e. a 1G guest on a 32G host > running fio but not top doesn't count). > So you intend on recommending something that you don't think is going to improve performance today and you know in certain scenarios is going to decrease performance? That doesn't seem right :-) I'm certainly open to changing the default once we get to a point where there's a demonstrable performance improvement from O_DIRECT but since I don't think it's a given that there will be, switching now seems like a premature optimization which has the side effect of reducing the performance of certain users. That seems like a Bad Thing to me. Regards, Anthony Liguori