[Qemu-devel] Re: [PATCH 10/10] Maintaing number of dirty pages

[Avi Kivity <avi@redhat.com>]

On 12/01/2010 06:56 PM, Anthony Liguori wrote:
> On 12/01/2010 10:52 AM, Avi Kivity wrote:
>> On 12/01/2010 06:49 PM, Anthony Liguori wrote:
>>>> We need actual measurements instead of speculations.
>>>
>>>
>>> Yes, I agree 100%.  I think the place to start is what I suggested 
>>> in a previous note in this thread, we need to measure actual stall 
>>> time in the guest.
>>
>> I'd actually start at the host.  How much time does 
>> ioctl(KVM_GET_DIRTY_LOG) take?  What's the percentage of time 
>> qemu_mutex is held?
>
> The question is, what really are the symptoms of the problem.  It's 
> not necessarily a bad thing if KVM_GET_DIRTY_LOG takes a long while 
> qemu_mutex is held.

Whether or not qemu_mutex is held, long KVM_GET_DIRTY_LONG runtimes are 
bad, since they are a lower bound on your downtime.  And 
KVM_GET_DIRTY_LOG does a lot of work, and invokes 
synchronize_srcu_expedited(), which can be very slow.

>
> Is the problem that the monitor responds slowly?  Is the problem that 
> the guest isn't consistently getting execution time?  Is the proper 
> simply that the guest isn't getting enough total execution time?

All three can happen if qemu_mutex is held too long.  The third can 
happen for other reasons (like KVM_GET_DIRTY_LOG holding the mmu 
spinlock for too long, can fix with O(1) write protection).

>
> I think we need to identify exactly what the problem is before we look 
> for sources.
>


-- 
error compiling committee.c: too many arguments to function