Re: [Qemu-devel] [RFC PATCH v5 3/3] Force auto-convegence of live migration

[Chegu Vinod <chegu_vinod@hp.com>]

On 5/9/2013 1:24 PM, Igor Mammedov wrote:
> On Thu,  9 May 2013 12:43:20 -0700
> Chegu Vinod <chegu_vinod@hp.com> wrote:
>
>>   If a user chooses to turn on the auto-converge migration capability
>>   these changes detect the lack of convergence and throttle down the
>>   guest. i.e. force the VCPUs out of the guest for some duration
>>   and let the migration thread catchup and help converge.
>>
> [...]
>> +
>> +static void mig_delay_vcpu(void)
>> +{
>> +    qemu_mutex_unlock_iothread();
>> +    g_usleep(50*1000);
>> +    qemu_mutex_lock_iothread();
>> +}
>> +
>> +/* Stub used for getting the vcpu out of VM and into qemu via
>> +   run_on_cpu()*/
>> +static void mig_kick_cpu(void *opq)
>> +{
>> +    mig_delay_vcpu();
>> +    return;
>> +}
>> +
>> +/* To reduce the dirty rate explicitly disallow the VCPUs from spending
>> +   much time in the VM. The migration thread will try to catchup.
>> +   Workload will experience a performance drop.
>> +*/
>> +void migration_throttle_down(void)
>> +{
>> +    if (throttling_needed()) {
>> +        CPUArchState *penv = first_cpu;
>> +        while (penv) {
>> +            qemu_mutex_lock_iothread();
> Locking it here and the unlocking it inside of queued work doesn't look nice.
Yes...but see below.
> What exactly are you protecting with this lock?
It was my understanding that BQL is supposed to be held when the vcpu 
threads start entering and executing in the qemu context (as qemu is not 
MP safe).. Still true?

In this specific use case I was concerned about the fraction of the time 
when a given vcpu thread is in the qemu context but not executing the 
callback routine...and was hence holding the BQL.Holding the BQL and 
g_usleep'ng is not only bad but would slow down the migration 
thread...hence the "doesn't look nice" stuff :(

For this specific use case If its not really required to even bother 
with the BQL then pl. do let me know.

Also pl. refer to version 3 of my patch....I was doing a g_usleep() in 
kvm_cpu_exec() and was not messing much with the BQL....but that was 
deemed as not a good thing either.

Thanks
Vinod

>
>> +            async_run_on_cpu(ENV_GET_CPU(penv), mig_kick_cpu, NULL);
>> +            qemu_mutex_unlock_iothread();
>> +            penv = penv->next_cpu;
>> +        }
>> +    }
>> +}
>
>