[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: Slowdowns comparing qemu-kvm.git to qemu.git: vcpu/thre
From: |
Amit Shah |
Subject: |
[Qemu-devel] Re: Slowdowns comparing qemu-kvm.git to qemu.git: vcpu/thread scheduling differences |
Date: |
Mon, 8 Feb 2010 23:05:19 +0530 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
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