Hello, In my testing of virtio-console, I found qemu-kvm.git introduces a lot of overhead in thread scheduling compared to qemu.git. My test sends a 260M file from the host to a guest via a virtio-console port and then computes the sha1sum of the file on the host as well as on the guest, compares the checksum and declares the result based on the checksum match. The test passes in all the scenarios listed below, indicating there's no unsafe data transfer. Repo Time taken ----- ---------- qemu.git < 1 m (typically 30s) qemu-kvm.git > 16m qemu-iothread ~ 5m The guest remains the same in all cases. I went back upto Oct 2009 in the git history to check if this was a regression; it is not. The qemu-kvm.git results are reproducible on qemu-kvm-0.12.git as well. The slowdown with qemu-iothread was reproduced by virtio-net as well: netperf results were better on qemu.git with iothread disabled than on qemu.git with iothread enabled. The virtio-console code currently puts only one buffer in the in_vq, meaning the host can only transfer 4k at a time before a guest consumes the data and makes the buffer available for subsequent transfers. Increasing the number of buffers available to 128 though "fixes" this -- qemu-kvm.git performance is much better in this case. I have some gprof results comparing qemu.git and qemu-kvm.git (30% of time in qemu-kvm.git is spent in main_loop_wait()), which I'm still analyzing and also going over the code paths that are different. I just thought I'd put out the observations out here so that others who have an idea can chime in or validate these results with other workloads. Amit -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
