[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
computed.
Paolo