[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] KVM brokenness due to IO thread changes
From: |
Marcelo Tosatti |
Subject: |
Re: [Qemu-devel] KVM brokenness due to IO thread changes |
Date: |
Tue, 28 Apr 2009 19:21:19 -0300 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Tue, Apr 28, 2009 at 03:09:57PM -0500, Anthony Liguori wrote:
>>>> this is a heads-up, maybe someone has some time to look into this over
>>>> the day: I seems like the IO thread changes caused a few regressions to
>>>> the KVM mode.
>>>>
>>>> When I keep this feature disabled, I see strange hick-ups of the event
>>>> delivery mechanism, and the guest stops once in a while for a second or
>>>> so. Attaching strace makes the whole process terminate early (looks like
>>>> it triggers a race in the signal handling). And when I enable the IO
>>>> thread, I immediately get a deadlock on qemu_global_mutex.
>>>>
>>> Yes its borked. The iothread should signal the vcpu thread whenever it
>>> wants to grab the mutex lock, because unlike kvm-userspace it does not
>>> drop the global mutex when entering guest mode (VCPU_RUN ioctl).
>>>
>>> Anthony will commit patches to fix that soon.
>>>
>>
>> Looking forward. It's far more efficient to test my infrastructure
>> changes against the KVM mode.
>>
>
> N.B. he's seeing issues with the IO thread disabled.
Jan,
Can you please provide more details on how to reproduce it? You're using
-nographic?
All I see, with ping -c 0.1, is an eventual ~= 25ms in response time:
64 bytes from 192.168.122.140: icmp_seq=80 ttl=64 time=0.008 ms
64 bytes from 192.168.122.140: icmp_seq=81 ttl=64 time=0.008 ms
64 bytes from 192.168.122.140: icmp_seq=82 ttl=64 time=0.008 ms
64 bytes from 192.168.122.140: icmp_seq=83 ttl=64 time=0.023 ms
64 bytes from 192.168.122.140: icmp_seq=84 ttl=64 time=0.008 ms
64 bytes from 192.168.122.140: icmp_seq=85 ttl=64 time=0.008 ms
64 bytes from 192.168.122.140: icmp_seq=86 ttl=64 time=0.009 ms
Which is also seen before the patches.
Or even better, if you can bisect it...
> I've not seen this myself and my patch doesn't fix that problem.
>
> Regards,
>
> Anthony Liguori