[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 05/10] migration: Fix the migrate auto converge
From: |
Gonglei (Arei) |
Subject: |
Re: [Qemu-devel] [PATCH 05/10] migration: Fix the migrate auto converge process |
Date: |
Tue, 18 Mar 2014 12:23:22 +0000 |
> < 'already got some feedback earlier on this and had this task in the
> list of things
> to work on... :) >
>
> Having the throttling start with some per-defined "degree" and then have
> that "degree" gradually increase ...either
>
> a) automatically as shown in Juan's example above (or)
>
> b) via some TBD user level interface...
>
> ...is one way to help with ensuring convergence for all cases.
>
> The issue of continuing to increase this "degree" of throttling is an
> obvious area of concern for the workload ( that is still trying to run
> in the VM). Would it it better to force the live migration to switch
> from the iterative pre-copy phase to the "downtime" phase ...if it fails
> to converge even after throttling it for a couple of iterations ? Doing
> so could result in a longer actual downtime. Hope to try this and
> see... but if anyone has inputs(other than doing post-copy etc) pl. do
> share.
>
>
> >
> > BTW, you are testing this with any workload to see that it improves?
>
> Yes. Please do share some data.
>
> >
> >
> >> + mig_throttle_on = true;
> >> + }
> > Vinod, what do you think?
> As is noted in the current code...the "logic" to detect the lack of
> convergence needs to be refined. If there is a better way to help detect
> same (and which covers these other cases like XBZRLE etc) then I am all
> for it. I do agree with Juan about the choice of magic numbers (i.e.
> one may not be better than the other).
>
> BTW, on a related note...
>
> I haven't used XBZRLE in the recent past (after having tried it in the
> early days). Does it now perform well with larger sized VMs running real
> world workloads ? Assume that is where you found that there was still
> need for forcing convergence ?
>
> Pl. do consider sharing some results about the type of workload and also
> the size of the VMs etc that you have tried with XBZRLE.
>
> > Do you have a workload to test this?
>
> Hmm... One can test this with memory intensive Java warehouse type of
> workloads (besides using synthetic workloads).
>
> Vinod
>
It will be more robust no matter whether xbzrle is enable. This patch don't aim
at performance.
BTW, the migration transfer speed which used in migration_thread also has same
problem.
I want to fix it, do you have any suggestion? Thanks.
> > Thanks, Juan.
> > .
> >
Best regards,
-Gonglei