qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Slow PXE boot in qemu.git (fast in qemu-kvm.git)


From: Stefan Hajnoczi
Subject: [Qemu-devel] Re: Slow PXE boot in qemu.git (fast in qemu-kvm.git)
Date: Sat, 9 Apr 2011 13:03:43 +0100

On Sat, Apr 9, 2011 at 1:50 AM, Anthony Liguori <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]