|
From: | Chegu Vinod |
Subject: | Re: [Qemu-devel] [RFC PATCH v5 3/3] Force auto-convegence of live migration |
Date: | Thu, 09 May 2013 16:00:38 -0700 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 |
On 5/9/2013 1:24 PM, Igor Mammedov wrote:
On Thu, 9 May 2013 12:43:20 -0700 Chegu Vinod <address@hidden> 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.
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?What exactly are you protecting with this lock?
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; + } + } +}
[Prev in Thread] | Current Thread | [Next in Thread] |