From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ENAFs-0003Iw-5j for qemu-devel@nongnu.org; Wed, 05 Oct 2005 10:28:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ENAFq-0003He-5K for qemu-devel@nongnu.org; Wed, 05 Oct 2005 10:28:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ENAFp-0003HV-VH for qemu-devel@nongnu.org; Wed, 05 Oct 2005 10:28:22 -0400 Received: from [209.234.73.41] (helo=kalmia.hozed.org) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1ENAFp-0006D0-Lx for qemu-devel@nongnu.org; Wed, 05 Oct 2005 10:28:21 -0400 Date: Wed, 5 Oct 2005 09:28:19 -0500 From: Troy Benjegerdes Subject: Re: [Qemu-devel] [patch] non-blocking disk IO Message-ID: <20051005142819.GP4612@kalmia.hozed.org> References: <4340D479.7030301@stanfordalumni.org> <4342E8B7.8050507@wasp.net.au> <43430A44.7010403@stanfordalumni.org> <4343B896.30806@wasp.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <4343B896.30806@wasp.net.au> 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 On Wed, Oct 05, 2005 at 03:27:18PM +0400, Brad Campbell wrote: > John Coiner wrote: > > > > >Thanks for the report. I was able to reproduce this. > > > >The problem was due to missing Makefile dependencies. The patch modifies > >'block_int.h', which is #included in several '.c' files. The file > >'block.c' recompiled at 'make' time, but 'block-qcow.c' didn't. The > >resulting '.o' files had different opinions about what a > >BlockDriverState struct looked like, which broke the qcow code. > > Having had it running for a while I did some performance tests and found no > performance gains _at all_, but then I'm running my entire system over the > network on an NFS filesystem (this machine has no disks in it). What network do you have between the client and nfs server? Also, what throughput do you see to the NFS server? (and what are the nfs 'wsize' and 'rsize' settings) > *NOW* having said that, one of the tricks I do to keep qemu from "going to > sleep" when running a long process like a big software install (sometimes > it appears to stall until I move the mouse around a bit) is to ping the > machine constantly from the host. > Prior to this patch I would get pings that varied from 1ms to 250ms. With > this patch I get a spread from about 1ms to 15ms tops. So it has smoothed > out the operation of the host noticably (also noticable in screen redraws > and UI responsiveness while under a heavy disk load). Does the stall still happen if you don't ping the guest?