[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.
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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]