qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

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