qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

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