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

[Jason J. Herne]

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 (address@hidden)