On 15/07/2015 14:40, Jason J. Herne wrote:
>>> 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.
Makes sense. On the other hand this wouldn't prevent callbacks from
piling up for a short time because...
> 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?
... you are talking about stolen time, and QEMU_CLOCK_VIRTUAL_RT does
count stolen time (stolen time is different for each VCPU, so you would
have a different clock for each VCPU).
QEMU_CLOCK_VIRTUAL and QEMU_CLOCK_VIRTUAL_RT(*) only pause across
stop/cont. (By the way, the two are the same with KVM).
However, something like
if (!atomic_xchg(&cpu->throttle_thread_scheduled, 1)) {
async_run_on_cpu(cpu, cpu_throttle_thread, NULL);
}
...
atomic_set(&cpu->throttle_thread_scheduled, 0);
g_usleep(...);
should be enough. You'd still have many timers that could starve the
VCPUs but, as you pointed out, in that case migration would hopefully
finish pretty fast.
Paolo
