Slow usernet from last qemu merge (~kvm-61)

Slow usernet from last qemu merge (~kvm-61)

[Dave Hansen]

I use '-net user' because it is simple for me to set up, and it has
always worked flawlessly.  On a recent update, though, I realized that I
couldn't use vi inside my guest because it had gotten too slow.  It
feels to me like lots of network latency, but is isn't _actual_ network
latency.

I can scp a very small file to a kvm-60 guest in ~3 seconds.  The same
file takes 15 seconds on kvm-61 with the exact same host kernel/modules,
guest kernel and guest disk.  I'm running the bios from the current git
tree.

I git bisected this behavior down to the qemu merge at:
e6fd8f045bf87e8518985d1f5a0102e5f5640d5a.

I also moved over to the qemu branch at just before the merge and built
that version of qemu by itself.  The scp time on that
non-kvm-accelerated version is about 4 seconds; barely slower than the
fast kvm, and way *FASTER* than current versions of kvm.  I'm quite sure
that this qemu was not accelerated because the boot was very, very slow.

I've tried ne2k, 8139 and e1000.  Changing between them didn't seem to
affect the problem.

Any ideas how to track this down further?

-- Dave


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Slow usernet from last qemu merge (~kvm-61)

[Anthony Liguori]

Dave Hansen wrote:
> I use '-net user' because it is simple for me to set up, and it has
> always worked flawlessly.  On a recent update, though, I realized that I
> couldn't use vi inside my guest because it had gotten too slow.  It
> feels to me like lots of network latency, but is isn't _actual_ network
> latency.
>   

When a socket becomes readable, that doesn't cause KVM to drop to 
userspace.  The only time it drops to userspace is when a signal is 
pending or when userspace has to handle something.  As things get more 
optimized, the lag between when a fd is readable and when we drop to 
userspace gets longer.  Long term, I think moving to an N+1 threading 
model, where there was a dedicated IO thread instead of handling IO in 
the main CPU thread, is the best solution to this general problem.

What we do for tap devices, is enable SIGIO on the tap fd.  This means 
that whenever the tap device is readable, we return more or less 
immediately to userspace.

The slirp code uses a lot of file descriptors but presumable, if you 
enabled SIGIO on all of them, it would fix the latency problem you are 
seeing.  I took a quick look and there doesn't seem to be an obvious 
place to hook the slirp code.  slirp/socket.c may be a good place to 
start.  Take a look at enable_fd_timer() in vl.c for an example of what 
you would need to call.  There were some patches floating around to 
rename that function and set SIGIO for all file descriptors.  I don't 
know if that also covered slirp.

FWIW, you'll probably get a better return on time investment by getting 
yourself going with tap.  If you use dnsmasq in the host, you can setup 
DNS, DHCP, TFTP, and BOOTP very easily.

Regards,

Anthony Liguori

> I can scp a very small file to a kvm-60 guest in ~3 seconds.  The same
> file takes 15 seconds on kvm-61 with the exact same host kernel/modules,
> guest kernel and guest disk.  I'm running the bios from the current git
> tree.
>
> I git bisected this behavior down to the qemu merge at:
> e6fd8f045bf87e8518985d1f5a0102e5f5640d5a.
>
> I also moved over to the qemu branch at just before the merge and built
> that version of qemu by itself.  The scp time on that
> non-kvm-accelerated version is about 4 seconds; barely slower than the
> fast kvm, and way *FASTER* than current versions of kvm.  I'm quite sure
> that this qemu was not accelerated because the boot was very, very slow.
>
> I've tried ne2k, 8139 and e1000.  Changing between them didn't seem to
> affect the problem.
>
> Any ideas how to track this down further?
>
> -- Dave
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/