On Sat, Apr 9, 2011 at 1:50 AM, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote: > On 04/08/2011 06:25 PM, Luiz Capitulino wrote: >> >> Hi there, >> >> Summary: >> >> - PXE boot in qemu.git (HEAD f124a41) is quite slow, more than 5 minutes. >> Got >> the problem with e1000, virtio and rtl8139. However, pcnet *works* >> (it's >> as fast as qemu-kvm.git) >> >> - PXE boot in qemu-kvm.git (HEAD df85c051) is fast, less than a minute. >> Tried >> with e1000, virtio and rtl8139 (I don't remember if I tried with pcnet) >> >> I tried with qemu.git v0.13.0 in order to check if this was a regression, >> but >> I got the same problem... >> >> Then I inspected qemu-kvm.git under the assumption that it could have a >> fix >> that wasn't commited to qemu.git. Found this: >> >> - commit 0836b77f0f65d56d08bdeffbac25cd6d78267dc9 which is merge, works >> >> - commit cc015e9a5dde2f03f123357fa060acbdfcd570a4 does not work (it's >> slow) >> >> I tried a bisect, but it brakes due to gcc4 vs. gcc3 changes. Then I >> inspected >> commits manually, and found out that commit 64d7e9a4 doesn't work, which >> makes >> me think that the fix could be in the conflict resolution of 0836b77f, >> which >> makes me remember that I'm late for diner, so my conclusions at this point >> are >> not reliable :) > > Can you run kvm_stat to see what the exit rates are? > > Maybe we're missing a coalesced io in qemu.git? It's also possible that > gpxe is hitting the apic or pit quite a lot. In gPXE's main loop it will do real <-> protected mode switches and poll hardware. It doesn't handle interrupts itself but sets up the 8254 timer chip. I once found that polling the keyboard only every couple of gPXE main loop iterations significantly speeds up network throughput under KVM. I never got around to auditing the entire main loop and implementing a clean patch. Anyway, kvm_stat is a good idea. It may be tickling qemu in a way that qemu-kvm is immune to. Stefan -- 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
