Re: [Qemu-devel] [PATCH v4 1/5] cpu: Provide vcpu throttling interface

["Jason J. Herne" <jjherne@linux.vnet.ibm.com>]

On 07/13/2015 11:14 AM, Paolo Bonzini wrote:
>
>
> On 13/07/2015 16:43, Jason J. Herne wrote:
>>>>
>>>> +    CPU_FOREACH(cpu) {
>>>> +        async_run_on_cpu(cpu, cpu_throttle_thread, NULL);
>>>> +    }
>>>> +
>>>> +    timer_mod(throttle_timer,
>>>> qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL_RT) +
>>>> +                                   CPU_THROTTLE_TIMESLICE);
>>>> +}
>>>
>>> This could cause callbacks to pile up I think.  David, do you have any
>>> idea how to fix it?
>>
>> I'm not sure how callbacks can pile up here. If the vcpus are running
>> then their thread's will execute the callbacks. If they are not running
>> then the use of QEMU_CLOCK_VIRTUAL_RT will prevent the callbacks from
>> stacking because the timer is not running, right?
>
> Couldn't the iothread starve the VCPUs?  They need to take the iothread
> lock in order to process the callbacks.
>

Yes, I can see the possibility here. I'm not sure what to do about it 
though.

Maybe this is wishful thinking :) But if the iothread lock cannot be 
acquired then
the cpu cannot run thereby preventing the guest from changing a ton of 
pages.
This will have the effect of indirectly throttling the guest which will 
allow
us to advance to the non-live phase of migration rather quickly. And again,
if we are starving on the iothread lock then the guest vcpus are not 
executing and
QEMU_CLOCK_VIRTUAL_RT is not ticking, right? This will also limit the 
number of
stacked callbacks to a very low number. Unless I've missing something?

-- 
-- Jason J. Herne (jjherne@linux.vnet.ibm.com)