[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v3] Throttle-down guest when live migration does

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v3] Throttle-down guest when live migration does not converge.
Date: Wed, 01 May 2013 19:03:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

Il 01/05/2013 18:34, Chegu Vinod ha scritto:
> On 5/1/2013 8:40 AM, Paolo Bonzini wrote:
>>> I shall make the suggested changes.
>>> Appreciate your review feedback on this part of the change.
> Hi Paolo.,
> Thanks for taking a look (BTW, I accidentally left out the "RFC"  in the
> patch subject line...my bad!).
>> Hi Vinod,
>> I think unfortunately it is not acceptable to make this patch work only
>> for KVM.  (It cannot work for Xen, but that's not a problem since Xen
>> uses a different migration mechanism; but it should work for TCG).
> Ok. I hadn't yet looked at TCG aspects etc. Will follow up offline...

If we do it right with run_on_cpu, it should just work with TCG.

>> Unfortunately, as you noted the run_on_cpu callbacks currently run
>> under the big QEMU lock.  We need to fix that first.  We have time
>> for that during 1.6.
> Ok.  Was under the impression that anytime a vcpu thread enters to do
> anything in qemu the BQL had to be held. So choose to go with
> run_on_cpu()  .  Will follow up offline on alternatives

run_on_cpu() is fine, but the problem is: 1) that run_on_cpu() is
synchronous, so the migration thread is paused too; 2) doing the usleep
directly in kvm_cpu_exec.

> "Holding" the vcpus in the host context (i.e. kvm module) itself is
> perhaps another way. Would need some handshakes (i.e. new ioctls ) with
> the kernel. Would that be acceptable way to proceed?

No, I think it's better to make the wait in userspace.  KVM could help
finding the CPUs to be stunned, since it is where the dirty bits are


reply via email to

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