From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FTMzh-0003zx-7b for qemu-devel@nongnu.org; Tue, 11 Apr 2006 13:49:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FTMzf-0003wv-MP for qemu-devel@nongnu.org; Tue, 11 Apr 2006 13:49:36 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FTMzf-0003wO-DS for qemu-devel@nongnu.org; Tue, 11 Apr 2006 13:49:35 -0400 Received: from [64.233.162.205] (helo=zproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FTN4a-0001l1-05 for qemu-devel@nongnu.org; Tue, 11 Apr 2006 13:54:40 -0400 Received: by zproxy.gmail.com with SMTP id n29so1139994nzf for ; Tue, 11 Apr 2006 10:49:34 -0700 (PDT) Message-ID: <6fe044190604111049j186d7c44oea9568ce1a8b54f3@mail.gmail.com> Date: Tue, 11 Apr 2006 10:49:34 -0700 From: "Kenneth Duda" Sender: ken.duda@gmail.com Subject: Re: [Qemu-devel] Network Performance between Win Host and Linux In-Reply-To: <200604111828.29361.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6fe044190604111020h47108190x23983325567fb51c@mail.gmail.com> <200604111828.29361.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org Paul, thanks for the note. In my case, the guest CPU is idle. The host CPU utilization is only 5 or 10 percent when running "find / -print > /dev/null" on the guest.=20 So I don't think guest interrupt latency is the issue for me in this case. My first guess is that qemu is asleep when the NFS response arrives on the slirp socket, and stays asleep for several milliseconds before deciding to check if anything has shown up via slirp. The problem is that vl.c's main_loop_wait() has separate calls to select() for slirp versus non-slirp fd's. I think this is the problem because strace reveals qemu blocking for several milliseconds at a time in select(), waking up with a SIGALRM, and then polling slirp and finding stuff to do there. These select calls don't appear hard to integrate, and the author seems to feel this would be a good idea anyway; from vl.c: #if defined(CONFIG_SLIRP) /* XXX: merge with the previous select() */ if (slirp_inited) { I will take a swing at this first. Please let me know if there's anything I should be aware of. Thanks, -Ken On 4/11/06, Paul Brook wrote: > On Tuesday 11 April 2006 18:20, Kenneth Duda wrote: > > I am also having severe performance problems using NFS-over-TCP on > > qemu-0.8 with a Linux host and guest. I will be looking at this > > today. My current theory is that the whole machine is going idle > > before qemu decides to poll kernel ring buffers holding packets the > > guest is transmitting, but if anyone has actual information, please > > let me know. > > You could be suffering from high interrupt latency. If the guest CPU is n= ot > idle then qemu only checks for interrupts (eg. the network RX interrupt) > every 1ms or 1/host_HZ seconds, whichever is greater. > If the guest CPU is idle it should respond immediately. > I wouldn't be surprised if this problem is worse when using kqemu. > > Paul >