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

Reply via email to