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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
