From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KoIsn-0008Rh-QL for qemu-devel@nongnu.org; Fri, 10 Oct 2008 10:22:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KoIsm-0008Qo-7D for qemu-devel@nongnu.org; Fri, 10 Oct 2008 10:22:21 -0400 Received: from [199.232.76.173] (port=54051 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KoIsm-0008Qk-1e for qemu-devel@nongnu.org; Fri, 10 Oct 2008 10:22:20 -0400 Received: from mx2.redhat.com ([66.187.237.31]:58440) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KoIsl-0001sk-JX for qemu-devel@nongnu.org; Fri, 10 Oct 2008 10:22:20 -0400 Message-ID: <48EF6459.6090404@redhat.com> Date: Fri, 10 Oct 2008 16:19:05 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU References: <48EE38B9.2050106@codemonkey.ws> <20081010081157.GA13431@volta.aurel32.net> <48EF49D8.3090002@codemonkey.ws> <200810101353.32933.paul@codesourcery.com> <48EF5EC0.1020809@codemonkey.ws> In-Reply-To: <48EF5EC0.1020809@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-15 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: qemu-devel@nongnu.org Cc: Chris Wright , Mark McLoughlin , kvm-devel , Laurent Vivier , Ryan Harper , Paul Brook Anthony Liguori wrote: >> >> This isn't entirely true. With IDE devices you don't have command >> queueing, so it's easy for a large write to stall subsequent reads >> for a relatively long time. >> I'm not sure how much this effects qemu, but I've definitely seen it >> happening on real hardware. >> > > I think that suggests we should have a cache=wb option and if people > report slow downs with IDE, we can observe if cache=wb helps. My > suspicion is that it's not going to have a practical impact because as > long as the operations are asynchronous (via DMA), then you're getting > native-like performance. > > My bigger concern is synchronous IO operations because then a guest > VCPU is getting far less time to run and that may have a cascading > effect on performance. IDE is limited to 256 sectors per transaction, or 128KB. If a sync transaction takes 5 ms, then your write rate is limited to 25 MB/sec. It's much worse if you're allocating qcow2 data, so each transaction is several sync writes. Fabrice's point also holds: if the guest is issuing many write transactions for some reason, you don't want them hammering the disk and killing your desktop performance if you're just developing, say, a new filesystem. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.