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 (jjhe...@linux.vnet.ibm.com)
