Re: [Qemu-devel] Network Performance between Win Host and Linux

[Kenneth Duda]

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. 
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 <address@hidden> 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 not
> 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
>