On (Mon) Feb 08 2010 [08:57:05], Anthony Liguori wrote: > On 02/08/2010 07:46 AM, Amit Shah wrote: >> 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 >> > > That very likely suggests that there are missing qemu_notify_events() in > qemu-kvm.git and you're getting blocked waiting for the next timer event > to fire. Hm, if that's the case, should virtio_notify() have a call to qemu_notify_event()? I added a qemu_notify_event() as the last statement in write_to_port() but that didn't help. > IOW, I assume that during the qemu-kvm.git run, the CPU isn't pegged at > 100% whereas it is in qemu.git. I think you're right; for qemu-kvm.git, I have seen various numbers: usage at an avg. of 2% and also at an avg. of 20% in different runs. I just did another run before writing this: 2% for qemu-kvm.git and 100% for qemu.git. 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