[Qemu-devel] Re: Slowdowns comparing qemu-kvm.git to qemu.git: vcpu/thread scheduling differences

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/08/2010 11:35 AM, Amit Shah wrote:
> 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()?
>    

No, basically, the problem will boil down to, the IO thread is 
select()'d waiting for an event to occur.  However, you've done 
something in the VCPU thread that requires the IO thread to run it's 
main loop.  You need to use qemu_notify_event() to force the IO thread 
to break out of select().

Debugging these problems are very difficult and the complexity here is 
the main reason the IO thread still hasn't been enabled by default in 
qemu.git.

I'd suggest looking at the main loop in qemu-kvm, seeing what isn't 
processed as a result of fd becoming readable/writable, and then making 
sure that any of those mechanisms you're relying on in virtio-console 
have the appropriate tie-ins to qemu_notify_event().

Regards,

Anthony Liguori